Integrated proxy interface for web based data management reports

ABSTRACT

An Intranet/Internet/Web-based data management tool that provides a common GUI enabling the requesting, customizing, scheduling and viewing of various types of unpriced call detail data reports pertaining to a customer&#39;s telecommunications network traffic. The Intranet/Internet/Web-based reporting system tool comprises a novel Web-based, client-server application that enables customers to access their own relevant data information timely, rapidly and accurately through a client GUI. A traffic view server is provided that enables periodic acquisition of data from the customer&#39;s telecommunications network at a user-specified frequency and configured to meet real-time traffic reporting requirements. The system infrastructure provided enables secure initiation, acquisition, and presentation of unpriced call detail and statistical data reports to customers.

CROSS-REFERENCE TO RELATED APPLICATIONS

The following patent application is based on and claims the benefit ofU.S. Provisional Patent Application Ser. No. 60/060,655, filed Sep. 26,1997.

FIELD OF THE INVENTION

The present invention relates generally to information delivery systemsand, particularly, to a novel, World Wide Web/Internet-based,telecommunications network data management reporting and presentationservice for customers of telecommunications service entities.

BACKGROUND OF THE INVENTION

Telecommunications service entities, e.g., MCI, AT&T, Sprint, and thelike, presently provide for the presentation and dissemination ofcustomer account and network data management information to theircustomers predominantly by enabling customers (clients) to directlydial-up, e.g., via a modem, to the entity's application servers toaccess their account information, or, alternatively, via dedicatedcommunication lines, e.g., ISDN, T-1, etc., enabling account informationrequests to be initiated through their computer workstation running, forexample, a Windows-based graphical user interface. The requests areprocessed by the entity's application servers, which retrieves therequested customer information, e.g., from one or more databases,processes and formats the information for downloading to the client'scomputer workstation.

Some types of data, e.g., “unpriced” call detail data pertains to acustomer's telecommunications traffic, i.e., number usage. This type ofdata is provided in near real-time, and is used by network managers tomake business decisions regarding their telecommunications networks. Asan example, the assignee telecommunications carrier MCI Corporationprovides an MCI ServiceView (“MSV”) product line for its businesscustomers which includes several client-server based data managementapplications. One of these applications, referred to as “TrafficView”,provides network traffic analysis/monitor information as provided froman MCI TrafficView server. Particularly, with respect to MCI'sTrafficView system, customers are provided with unpriced call detaildata, e.g., relating to their toll free networks.

The current TrafficView architecture is organized primarily as a batchmidrange-based server data delivery mechanism with the data beingtypically “canned” delivered at predetermined times with predeterminedformats. Additional trending, analysis, and data managementfunctionality is maintained by the customers in workstation-basedsoftware provided to customers for installation at customer sites ontheir PCS.

While effective for its purpose, the current data management andpresentation architecture are limited in that reports generated are of anarrow view, and are delivered at predetermined times with predeterminedformats. These prior art reporting systems do not enable the generationof ad-hoc reports. Moreover, legacy platforms containing reporting dataare reaching the architectural limits of scalability in terms of thetotal customers they can support, total online data they can present,total historical data they can keep and type and number of applicationsthey can support. This simply is not sufficient for an increasing numberof customers who, to remain competitive, are required to have updatedand real-time access to their data to enable them to make their criticalbusiness decisions quicker. Moreover, there are a variety of independentdata management tools and legacy reporting systems having disparatesystems and infrastructures providing little or no cross applicationinteroperability and data sharing, thus, requiring customers to useseparate applications to gain access to their data.

It would thus be highly desirable to provide a data management productthat is a Web-based (Internet and Intranet) client-server applicationfor providing customers with information relating to theirtelecommunications network traffic and usage in a variety of detailedreport formats.

It would additionally be highly desirable to provide a Web-based(Internet and Intranet) data management tool having a Web-basedclient-server application which provides expedient and secure dataaccess and reporting services to customers in real-time, from any webbrowser on any computer workstation anywhere in the world.

SUMMARY OF THE INVENTION

The present invention is directed to a novel Intranet/Internet/Web-baseddata management system that provides a common GUI enabling therequesting, customizing, scheduling and viewing of various types ofreports pertaining to customer's telecommunications network traffic,i.e., unpriced “traffic view” data. The Intranet/Internet/Web-based datamanagement system comprises a Web-based, client-server application thatenables customers to access their own relevant unpriced network trafficdata information timely, rapidly and in a secure manner through the aclient GUI. A client server application infrastructure enablesprocessing, generation, and reporting of customer's real-time and ratedinbound and outbound telecommunications traffic for network management,call center management and customer calling pattern analysis functions.

The system further employs a platform-independent, i.e., JAVA-based,network centric GUI client presentation layer and anobjects/dispatcher/proxy layer access architecture.

Particularly, the telecommunications data management/system architectureis integrated with a novel Web/Internet-based reporting tool, referredto as “StarWRS”, described in co-pending U.S. patent application Ser.No. ______ (D#11050).

The StarWRS web-based reporting tool comprises a layer functioning toenable customers to request reporting functionality across the Internet.This report request functionality includes routing requests toappropriate databases, e.g., real-time reporting requests will besatisfied by real-time database. Additionally, the interface providescustomers with the ability to schedule and prioritize reports, formatreport request result sets, and provides for load balancing, reportrequest validation, query generation and execution. Through a commonGUI, customers are enabled to access their own unmetered network trafficdata, i.e., usage analysis data.

In accordance with the principles of the present invention, there isprovided a Web/Internet based reporting system for communicating calldetail information relating to traffic pertaining to a customer'stelecommunications network to a client workstation via an integratedinterface comprising: a client browser application located at the clientworkstation for enabling interactive Web based communications with thereporting system, the client workstation identified with a customer andproviding the integrated interface; at least one secure server formanaging client sessions over the Internet, the secure server supportinga secure socket connection enabling encrypted communication between thebrowser application client and the secure server; a report managerserver in communication with at least one secure server for maintainingan inventory of reporting items associated with a customer, thereporting items comprising report data types and report customizationfeatures for reports to be generated for the customer; a data retrievaldevice for retrieving customer specific data from the customer'stelecommunications network at pre-determined times; and, a requestorapplication enabling the customer to communicate a data report requestmessage via the integrated interface to the report manager server, therequest message comprising a metadata description of particularreporting items to be retrieved, the metadata description of particularreporting items being forwarded to the retrieval device, and theretrieval device obtaining customer specific data in accordance with themetadata request, whereby customer-specific retrieved data and themetadata description of the reporting items are communicated to theclient workstation and utilized to generate a completed report forpresentation to the customer.

BRIEF DESCRIPTION OF THE DRAWINGS

Further features and advantages of the invention will become morereadily apparent from a consideration of the following detaileddescription set forth with reference to the accompanying drawings, whichspecify and show preferred embodiments of the invention, wherein likeelements are designated by identical references throughout the drawingsand in which:

FIG. 1 illustrates the software architecture component comprising athree-tiered structure;

FIG. 2 is a diagrammatic overview of the software architecture of thenetworkMCI Interact system;

FIG. 3 is an illustrative example of a backplane architecture schematic;

FIG. 4 illustrates an example client GUI presented to theclient/customer as a browser web page;

FIG. 5 is a diagram depicting the physical networkMCI Interact systemarchitecture;

FIG. 6 is a block diagram depicting the physical architecture of theStarWRS component 200 of the networkMCI Interact system;

FIG. 7 is a schematic diagram depicting the nMCI Interact Traffic Viewsystem 500 for reporting customer's unpriced call detail datasubstantially in real-time;

FIG. 8 is an general flow diagram of the process by which the TVS server550 gets data.

FIG. 9 is a detailed flow diagram depicting the internal TVS serverprocesses for receiving customer TVS enablement data from order entryand CORE systems;

FIG. 10 is a high-level diagram depicting TCR data flow betweenprocesses internal to the TVS server;

FIG. 11 is a high-level flow diagram depicting TVS report generationprocess;

FIGS. 12(a)-12(d) illustrate the end-to-end process 700 for fulfillingunpriced call detail data report requests;

FIG. 13 illustrates a logical message format sent from the clientbrowser to the desired middle tier server for a particular application;and,

FIGS. 14(a) and 14(b) are schematic illustrations showing the messageformat passed between the Dispatcher server and the application specificproxy (FIG. 14(a)) and the message format passed between the applicationspecific proxy back to the Dispatcher server (FIG. 14(b)).

DETAILED DESCRIPTION OF THE INVENTION

The present invention is one component of an integrated suite ofcustomer network management and report applications using a Web browserparadigm. Known as the networkMCI Interact system (“nMCI Interact”) suchan integrated suite of Web-based applications provides an invaluabletool for enabling customers to manage their telecommunication assets,quickly and securely, from anywhere in the world.

As described in co-pending U.S. patent application Ser. No. ______(D#11038), the nMCI Interact system architecture is basically organizedas a set of common components comprising the following:

1) an object-oriented software architecture detailing the client andserver based aspect of nMCI Interact;

2) a network architecture defining the physical network needed tosatisfy the security and data volume requirements of the networkMCISystem;

3) a data architecture detailing the application, back-end or legacydata sources available for networkMCI Interact; and

4) an infrastructure covering security, order entry, fulfillment,billing, self-monitoring, metrics and support.

Each of these common component areas will be generally discussedhereinbelow. A detailed descriptions of each of these components can befound in a related, co-pending U.S. patent application Ser. No.00/000,000 (Attorney Docket 11038) entitled INTEGRATED CUSTOMERINTERFACE SYSTEM FOR COMMUNICATIONS NETWORK MANAGEMENT, the disclosureof which is incorporated herein by reference thereto.

FIG. 1 is a diagrammatic illustration of the software architecturecomponent in which the present invention functions. A first or clienttier 10 of software services are resident on a customer work station 10and provides customer access to the enterprise system, having one ormore downloadable application objects directed to front end businesslogic, one or more backplane service objects for managing sessions, oneor more presentation services objects for the presentation of customeroptions and customer requested data in a browser recognizable format anda customer supplied browser for presentation of customer options anddata to the customer and for internet communications over the publicInternet. Additionally applications are directed to front end servicessuch as the presentation of data in the form of tables and charts, anddata processing functions such as sorting and summarizing in a mannersuch that multiple programs are combined in a unified application suite.

A second or middle tier 12, is provided having secure web servers andback end services to provide applications that establish user sessions,govern user authentication and their entitlements, and communicate withadaptor programs to simplify the interchange of data across the network.

A third or back end tier 15 having applications directed to legacy backend services including database storage and retrieval systems and one ormore database servers for accessing system resources from one or morelegacy hosts.

Generally, as explained in co-pending U.S. patent application Ser. No.______ (D#11040), entitled GRAPHICAL USER INTERFACE FOR WEB ENABLEDAPPLICATIONS, the disclosure of which is incorporated herein byreference thereto, the customer workstation includes client softwarecapable of providing a platform-independent, browser-based, consistentuser interface implementing objects programmed to provide a reusable andcommon GUI abstraction and problem-domain abstractions. Morespecifically, the client-tier software is created and distributed as aset of Java classes including the applet classes to provide anindustrial strength, object-oriented environment over the Internet.Application-specific classes are designed to support the functionalityand server interfaces for each application with the functionalitydelivered through the system being of two-types: 1) cross-product, forexample, inbox and reporting functions, and 2) product specific, forexample, toll free network management or Call Manager functions. Thesystem is capable of delivering to customers the functionalityappropriate to their product mix.

FIG. 2 is a diagrammatic overview of the software architecture of thenetworkMCI Interact system including: the Customer Browser (a.k.a. theClient) 20; the Demilitarized Zone (DMZ) 17 comprising a Web Serverscluster 24; the MCI Intranet Dispatcher Server 26; and the MCI IntranetApplication servers 30, and the data warehouses, legacy systems, etc.40.

The Customer Browser 20, is browser enabled and includes clientapplications responsible for presentation and front-end services. Itsfunctions include providing a user interface to various MCI services andsupporting communications with MCI's Intranet web server cluster 24. Asillustrated in FIG. 3, and more specifically described in theabove-mentioned, co-pending U.S. patent application Ser. No. ______entitled GRAPHICAL USER INTERFACE FOR WEB ENABLED APPLICATIONS, theclient tier software is responsible for presentation services to thecustomer and generally includes a web browser 14 and additionalobject-oriented programs residing in the client workstation platform 20.The client software is generally organized into a component architecturewith each component generally comprising a specific application,providing an area of functionality. The applications generally areintegrated using a “backplane” services layer 12 which provides a set ofservices to the application objects which provide the front end businesslogic and manages their launch. The networkMCI Interact common set ofobjects provide a set of services to each of the applications suchas: 1) session management; 2) application launch; 3) inter-applicationcommunications; 4) window navigation among applications; 5) logmanagement; and 6) version management.

The primary common object services include: graphical user interface(GUI); communications; printing; user identity, authentication, andentitlements; data import and export; logging and statistics; errorhandling; and messaging services.

FIG. 3 is a diagrammatic example of a backplane architecture schemeillustrating the relationship among the common objects. In this example,the backplane services layer 12 is programmed as a Java applet which canbe loaded and launched by the web browser 14. With reference to FIG. 3,a typical user session starts with a web browser 14 creating a backplane12, after a successful logon. The backplane 12, inter alia, presents auser with an interface for networkMCI Interact application management. Atypical user display provided by the backplane 12 may show a number ofapplications the user is entitled to run, each application representedby buttons depicted in FIG. 3 as buttons 58 a,b,c selectable by theuser. As illustrated in FIG. 3, upon-selection of an application, thebackplane 12 launches that specific application, for example, ServiceInquiry 54 a or Alarm Monitor 54 b, by creating the application object.In processing its functions, each application in turn, may utilizecommon object services provided by the backplane 12. FIG. 3 showsgraphical user interface objects 56 a,b created and used by a respectiveapplication 54 a,b for its own presentation purposes.

FIG. 4 illustrates an example client GUI presented to theclient/customer as a browser web page 80 providing, for example, a suite70 of network management reporting applications including: MCI TrafficMonitor 72; an alarm monitor 73; a Network Manager 74 and IntelligentRouting 75. Access to network functionality is also provided throughReport Requester 76, which provides a variety of detailed reports forthe client/customer and a Message Center 77 for providing enhancementsand functionality to traditional e-mail communications.

As shown in FIGS. 3 and 4, the browser resident GUI of the presentinvention implements a single object, COBackPlane which keeps track ofall the client applications, and which has capabilities to start, stop,and provide references to any one of the client applications.

The backplane 12 and the client applications use a browser 14 such asthe Microsoft Explorer versions 4.01 or higher for an access anddistribution mechanism. Although the backplane is initiated with abrowser 14, the client applications are generally isolated from thebrowser in that they typically present their user interfaces in aseparate frame, rather than sitting inside a Web page.

The backplane architecture is implemented with several primary classes.These classes include COBackPlane, COApp, COAppImpl, COParm. andCOAppFrame classes. COBackPlane 12 is an application backplane whichlaunches the applications 54 a, 54 b, typically implemented as COApp.COBackPlane 12 is generally implemented as a Java applet and is launchedby the Web browser 14. This backplane applet is responsible forlaunching and closing the COApps.

When the backplane is implemented as an applet, it overrides standardApplet methods init( ), start( ), stop( ) and run( ). In the init( )method, the backplane applet obtains a COUser user context object. TheCOUser object holds information such as user profile, applications andtheir entitlements. The user's configuration and applicationentitlements provided in the COUser context are used to construct theapplication toolbar and Inbox applications. When an application toolbaricon is clicked, a particular COApp is launched by launchApp( ) method.The launched application then may use the backplane forinter-application communications, including retrieving Inbox data.

The COBackPlane 12 includes methods for providing a reference to aparticular COApp, for interoperation. For example, the COBackPlane classprovides a getApp( ) method which returns references to applicationobjects by name. Once retrieved in this manner, the application object'spublic interface may be used directly.

The use of a set of common objects for implementing the variousfunctions provided by the system of the present invention, andparticularly the use of browser based objects to launch applications andpass data therebetween is more fully described in the above-referenced,copending application GRAPHICAL USER INTERFACE FOR WEB ENABLEDAPPLICATIONS.

As shown in FIG. 2, the aforesaid objects will communicate the data byestablishing a secure TCP messaging session with one of the DMZnetworkMCI Interact Web servers 24 via an Internet secure communicationspath 22 established, preferably, with a secure sockets SSL version ofHTTPS. The DMZ networkMCI Interact Web servers 24 function to decryptthe client message, preferably via the SSL implementation, and unwrapthe session key and verify the users session. After establishing thatthe request has come from a valid user and mapping the request to itsassociated session, the DMZ Web servers 24 will re-encrypt the requestusing symmetric encryption and forward it over a second connection 23 tothe dispatch server 26 inside the enterprise Intranet.

As described in greater detail in co-pending U.S. patent ApplicationSer. No. ______ (D#11043) entitled SECURE CUSTOMER INTERFACE FORWEB-BASED DATA MANAGEMENT, the contents and disclosure of which isincorporated by reference as if fully set forth herein, a networkMCIInteract session is designated by a logon, successful authentication,followed by use of server resources, and logoff. However, the world-wideweb communications protocol uses HTTP, a stateless protocol, each HTTPrequest and reply is a separate TCP/IP connection, completelyindependent of all previous or future connections between the sameserver and client. The nMCI Interact system is implemented with a secureversion of HTTP such as S-HTTP or HTTPS, and preferably utilizes the SSLimplementation of HTTPS. The preferred embodiment uses SSL whichprovides a cipher spec message which provides server authenticationduring a session. The preferred embodiment further associates a givenHTTPS request with a logical session which is initiated and tracked by a“cookie jar server” 28 to generate a “cookie” which is a uniqueserver-generated key that is sent to the client along with each reply toa HTTPS request. The client holds the cookie and returns it to theserver as part of each subsequent HTTPS request. As desired, either theWeb servers 24, the cookie jar server 28 or the Dispatch Server 26, maymaintain the “cookie jar” to map these keys to the associated session. Aseparate cookie jar server 28, as illustrated in FIG. 2 has been founddesirable to minimize the load on the dispatch server 26. This form ofsession management also functions as an authentication of each HTTPSrequest, adding an additional level of security to the overall process.

As illustrated in FIG. 2, after one of the DMZ Web servers 24 decryptsand verifies the user session, it forwards the message through afirewall 25 b over a TCP/IP connection 23 to the dispatch server 26 on anew TCP socket while the original socket 22 from the browser isblocking, waiting for a response. The dispatch server 26 will unwrap anouter protocol layer of the message from the DMZ services cluster 24,and will reencrypt the message with symmetric encryption and forward themessage to an appropriate application proxy via a third TCP/IP socket27. While waiting for the proxy response all three of the sockets 22,23, 27 will be blocking on a receive. Specifically, once the message isdecrypted, the wrappers are examined to reveal the user and the targetmiddle-tier (Intranet application) service for the request. Afirst-level validation is performed, making sure that the user isentitled to communicate with the desired service. The user'sentitlements in this regard are fetched by the dispatch server 26 fromStarOE server 49 at logon time and cached.

If the requestor is authorized to communicate with the target service,the message is forwarded to the desired service's proxy. Eachapplication proxy is an application specific daemon which resides on aspecific Intranet server, shown in FIG. 2 as a suite of mid-rangeservers 30. Each Intranet application server of suite 30 is generallyresponsible for providing a specific back-end service requested by theclient, and, is additionally capable of requesting services from otherIntranet application servers by communicating to the specific proxyassociated with that other application server. Thus, an applicationserver not only can offer its browser a client to server interfacethrough the proxy, but also may offer all its services from its proxy toother application servers. In effect, the application servers requestingservice are acting as clients to the application servers providing theservice. Such mechanism increases the security of the overall system aswell as reducing the number of interfaces.

The network architecture of FIG. 2 may also include a variety ofapplication specific proxies having associated Intranet applicationservers including: a StarOE proxy for the StarOE application server 39for handling authentication order entry/billing; an Inbox proxy for theInbox application server 31, which functions as a container forcompleted reports, call detail data and marketing news messages, aReport Manager Proxy capable of communicating with a system-specificReport Manager server 32 for generating, managing and scheduling thetransmission of customized reports including, for example: call usageanalysis information provided from the StarODS server 33; networktraffic analysis/monitor information provided from the Traffic viewserver 34; virtual data network alarms and performance reports providedby Broadband server 35; trouble tickets for switching, transmission andtraffic faults provided by Service Inquiry server 36; and toll freerouting information provided by Toll Free Network Manager server 37.

As partially shown in FIG. 2, it is understood that each Intranet serverof suite 30 communicates with one or several consolidated networkdatabases which include each customer's network management informationand data. In the present invention the Services Inquiry server 36includes communication with MCI's Customer Service Management legacyplatform 40(a). Such network management and customer network data isadditionally accessible by authorized MCI management personnel. As shownin FIG. 2, other legacy platforms 40(b), 40(c) and 40(d) may alsocommunicate individually with the Intranet servers for servicingspecific transactions initiated at the client browser. The illustratedlegacy platforms 40(a)-(d) are illustrative only and it is understoodother legacy platforms may be interpreted into the network architectureillustrated in FIG. 2 through an intermediate midrange server 30.

Each of the individual proxies may be maintained on the dispatch server26, the related application server, or a separate proxy server situatedbetween the dispatch server 26 and the midrange server 30. The relevantproxy waits for requests from an application client running on thecustomer's workstation 10 and then services the request, either byhandling them internally or forwarding them to its associated Intranetapplication server 30. The proxies additionally receive appropriateresponses back from an Intranet application server 30. Any data returnedfrom the Intranet application server 30 is translated back to clientformat, and returned over the internet to the client workstation 10 viathe Dispatch Server 26 and at one of the web servers in the DMZ Servicescluster 24 and a secure sockets connection. When the resultant responseheader and trailing application specific data are sent back to theclient browser from the proxy, the messages will cascade all the wayback to the browser 14 in real time, limited only by the transmissionlatency speed of the network.

The networkMCI Interact middle tier software includes a communicationscomponent offering three (3) types of data transport mechanisms: 1)Synchronous; 2) Asynchronous; and 3) Bulk transfer. Synchronoustransaction is used for situations in which data will be returned by theapplication server 40 quickly. Thus, a single TCP connection will bemade and kept open until the full response has been retrieved.

Asynchronous transaction is supported generally for situations in whichthere may be a long delay in application server 40 response.Specifically, a proxy will accept a request from a customer or client 10via an SSL connection and then respond to the client 10 with a uniqueidentifier and close the socket connection. The client 10 may then pollrepeatedly on a periodic basis until the response is ready. Each pollwill occur on a new socket connection to the proxy, and the proxy willeither respond with the resultant data or, respond that the request isstill in progress. This will reduce the number of resource consuming TCPconnections open at any time and permit a user to close their browser ordisconnect a modem and return later to check for results.

Bulk transfer is generally intended for large data transfers and areunlimited in size. Bulk transfer permits cancellation during a transferand allows the programmer to code resumption of a transfer at a laterpoint in time.

FIG. 5 is a diagram depicting the physical networkMCI Interact systemarchitecture 10. As shown in FIG. 5, the system is divided into threemajor architectural divisions including: 1) the customer workstation 20which include those mechanisms enabling customer connection to theSecure web servers 24; 2) a secure network area 17, known as theDeMilitarized Zone “DMZ” set aside on MCI premises double firewalledbetween the both the public Internet 25 and the MCI Intranet to preventpotentially hostile customer attacks; and, 3) the MCI Intranet MidrangeServers 30 and Legacy Mainframe Systems 40 which comprise the back endbusiness logic applications.

As illustrated in FIG. 5, the present invention includes a double orcomplex firewall system that creates a “demilitarized zone” (DMZ)between two firewalls 25 a, 25 b. In the preferred embodiment, one ofthe firewalls 29 includes port specific filtering routers, which mayonly connect with a designated port address. For example, router 49(firewall 25(a)) may connect only to the addresses set for the HydraWeb®(or web servers 24) within the DMZ, and router 55 (firewall 25(b)) mayonly connect to the port addresses set for the dispatch server 26 withinthe network. In addition, the dispatch server 26 connects with anauthentication server, and through a proxy firewall to the applicationservers. This ensures that even if a remote user ID and password arehijacked, the only access granted is to one of the web servers 24 or tointermediate data and privileges authorized for that user. Further, thehijacker may not directly connect to any enterprise server in theenterprise intranet beyond the DMZ, thus ensuring internal companysystem security and integrity. Even with a stolen password, the hijackermay not connect to other ports, root directories or application serverswithin the enterprise system, and the only servers that may be sabotagedor controlled by a hacker are the web servers 24.

The DMZ 17 acts as a double firewall for the enterprise intranet becauseof the double layer of port specific filtering rules. Further, the webservers 24 located in the DMZ never store or compute actual customersensitive data. The web servers only transmit the data in a formsuitable for display by the customer's web browser. Since the DMZ webservers do not store customer data, there is a much smaller chance ofany customer information being jeopardized in case of a security breach.In the preferred embodiment, firewalls or routers 47,49 are acombination of circuit gateways and filtering gateways or routers usingpacket filtering rules to grant or deny access from a source address toa destination address. All connections from the internal applicationservers are proxied and filtered through the dispatcher before reachingthe web servers 24. Thus it appears to any remote site, that theconnection is really with the DMZ site, and identity of the internalserver is doubly obscured. This also prevents and direct connectionbetween any external and any internal network or intranet computer.

The filtering firewalls 25(a), (b) may also pass or block specific typesof Internet protocols. For example, FTP can be enabled only forconnections to the In-Box server 31, and denied for all otherdestinations. SMTP can also be enabled to the In-Box server, but Telnetdenied. The In-box server 31 is a store and forward server for clientdesignated reports, but even in this server, the data and metadata areseparated to further secure the data, as will be described.

As previously described, the customer access mechanism is a clientworkstation 20 employing a Web browser 14 for providing the access tothe networkMCI Interact system via the public Internet 15. When asubscriber connects to the networkMCI Interact Web site by entering theappropriate URL, a secure TCP/IP communications link 22 is establishedto one of several Web servers 24 located inside a first firewall 25 a inthe DMZ 17. Preferably at least two web servers are provided forredundancy and failover capability. In the preferred embodiment of theinvention, the system employs SSL encryption so that communications inboth directions between the subscriber and the networkMCI Interactsystem are secure.

In the preferred embodiment, all DMZ Secure Web servers 24 arepreferably DEC 4100 systems having Unix or NT-based operating systemsfor running services such as HTTPS, FTP, and Telnet over TCP/IP. The webservers may be interconnected by a fast Ethernet LAN running at 100Mbit/sec or greater, preferably with the deployment of switches withinthe Ethernet LANs for improved bandwidth utilization. One such switchingunit included as part of the network architecture is a HydraWEB® unit45, manufactured by HydraWEB Technologies, Inc., which provides the DMZwith a virtual IP address so that subscriber HTTPS requests receivedover the Internet will always be received. The Hydraweb unit 45implements a load balancing algorithm enabling intelligent packetrouting and providing optimal reliability and performance byguaranteeing accessibility to the “most available” server. Itparticularly monitors all aspects of web server health from CPU usage,to memory utilization, to available swap space so that Internet/Intranetnetworks can increase their hit rate and reduce Web server managementcosts. In this manner, resource utilization is maximized and bandwidth(throughput) is improved. It should be understood that a redundantHydraweb® unit may be implemented in a Hot/Standby configuration withheartbeat messaging between the two units (not shown). Moreover, thenetworkMCI Interact system architecture affords web server scaling, bothin vertical and horizontal directions. Additionally, the architecture issuch that new secure web servers 24 may be easily added as customerrequirements and usage increases.

As shown in FIG. 5, the most available Web server 24 receives subscriberHTTPS requests, for example, from the HydraWEB™ 45 over a connection 44a and generates the appropriate encrypted messages for routing therequest to the appropriate MCI Intranet midrange web server overconnection 44 b, router 55 and connection 23. Via the Hydraweb unit 45,a TCP/IP connection 38 links the Secure Web server 24 with the MCIIntranet Dispatcher server 26.

Further as shown in the DMZ 17 is a second RTM server 52 having its ownconnection to the public Internet via a TCP/IP connection 48. Asdescribed in co-pending U.S. patent application Ser. No. ______, (D#11045) entitled INTEGRATED PROXY INTERFACE FOR WEB BASEDTELECOMMUNICATIONS MANAGEMENT TOOLS, incorporated by reference as iffully set forth herein, this RTM server provides real-time sessionmanagement for subscribers of the networkMCI Interact Real TimeMonitoring system. An additional TCP/IP connection 48 links the RTM Webserver 52 with the MCI Intranet Dispatcher server 26. As further shownin FIG. 5, a third router 65 is provided for routing encryptedsubscriber messages from the RTM Web server 52 to the Dispatcher server26 inside the second firewall. Although not shown, each of the routers55, 65 may additionally route signals through a series of other routersbefore eventually being routed to the nMCI Interact Dispatcher server26. In operation, each of the Secure servers 24 function to decrypt theclient message, preferably via the SSL implementation, and unwrap thesession key and verify the users session from the COUser objectauthenticated at Logon.

After establishing that the request has come from a valid user andmapping the request to its associated session, the Secure Web servers 24will re-encrypt the request using symmetric RSA encryption and forwardit over a second secure socket connection 23 to the dispatch server 26inside the enterprise Intranet.

As described herein, and in greater detail in co-pending U.S. patentapplication Ser. No. ______ (D# 11038), the data architecture componentof networkMCI Interact reporting system is focused on the presentationof real time (un-priced) call detail data, such as provided by MCI'sTrafficView Server 34, and priced call detail data and reports, such asprovided by MCI's StarODS Server 33 in a variety of user selectedformats.

All reporting is provided through a Report Requestor GUI applicationinterface which support spreadsheet, a varity of graph and chart type,or both simultaneously. For example, the spreadsheet presentation allowsfor sorting by any arbitrary set of columns. The report viewer may alsobe launched from the inbox when a report is selected.

Report management related data is also generated which includes 1)report profiles defining the types of reports that are available, fieldsfor the reports, default sort options and customizations allowed; and 2)report requests defining customer specific report requests includingreport type, report name, scheduling criteria, and subtotal fields. Thistype of data will be resident in an Inbox server database and managed bythe Inbox server.

The Infrastructure component of the nMCI Reporting system includes meansfor providing secure communications regardless of the data content beingcommunicated. As described in detail in above-referenced, co-pendingU.S. patent application Ser. No. ______ (D#11043), the nMCI Interactsystem security infrastructure includes: 1) authentication, includingthe use of passwords and digital certificates; 2) public key encryption,such as employed by a secure sockets layer (SSL) encryption protocol; 3)firewalls, such as described above with reference to the networkarchitecture component; and 4) non-repudiation techniques to guaranteethat a message originating from a source is the actual identifiedsender. One technique employed to combat repudiation includes use of anaudit trail with electronically signed one-way message digests includedwith each transaction.

Another component of the nMCI Interact infrastructure includes orderentry, which is supported by the Order Entry (“StarOE”) server. Thegeneral categories of features to be ordered include: 1) PricedReporting; 2) Real-time reporting; 3) Priced Call Detail; 4) Real TimeCall Detail; 5) Broadband SNMP Alarming; 6) Broadband Reports; 7)Inbound RTM; 8) Outbound RTM; 9) Toll Free Network Manager; and 10) CallManager. The order entry functionality is extended to additionallysupport 11) Event Monitor; 12) Service Inquiry; 13) Outbound NetworkManager; 14) Portfolio; and, 15) Client View.

The Self-monitoring infrastructure component for nMCI Interact is theemployment of mid-range servers that support SNMP alerts at the hardwarelevel. In addition, all software processes must generate alerts based onprocess health, connectivity, and availability of resources (e.g., diskusage, CPU utilization, database availability).

The Metrics infrastructure component for nMCI Interact is the employmentof means to monitor throughput and volumes at the Web servers,dispatcher server, application proxies and mid-range servers. Metricsmonitoring helps in the determination of hardware and network growth.

To provide the areas of functionality described above, the client tier10 is organized into a component architecture, with each componentproviding one of the areas of functionality. As explained in furtherdetail in co-pending U.S. patent application Ser. No. ______ (Atty. D#11040), the client-tier software is organized into a “component”architecture supporting such applications as inbox fetch and inboxmanagement, report viewer and report requester, TFNM, Event Monitor,Broadband, Real-Time Monitor, and system administration applications.Further functionality integrated into the software architecture includesapplications such as Outbound Network Manager, Call Manager, ServiceInquiry and Client View.

The present invention focuses on the client and middle-tier service andapplication proxy components that enable customers to request, specify,customize, schedule and receive their unpriced telecommunicationsnetwork traffic call detail data and account information in the form ofreports that are generated by a back-end application server. Referred toherein as “StarWRS,” this WWW/Internet Reporting System 200, as shown inFIG. 6, comprises the following components and messaging interfaces:

1) those components associated with the Client GUI front end including areport requestor client application 212, a report viewer clientapplication 215 and, an Inbox client application 210 which implement thelogical processes associated with a “Java Client”, i.e., employs Javaapplets launched from the backplane (FIG. 3) that enable the display andcreation of reports and graphs based on the fields of the displayedreports, and, allows selection of different reporting criteria andoptions for a given report; and,

2) those middle-tier server components enabling the above-mentionedreporting functionality including: a Report Manager server 250, a Reportscheduler server 260, and an Inbox Server 270. Also shown in FIG. 6 arethe system Order Entry client application 280 and a corresponding OrderEntry Server 285 supporting the StarWRS reporting functionality as willbe described.

Each of these components will now be described with greaterparticularity hereinbelow.

The Report Manager (“RM”) server 250 is an application responsible forthe synchronization of report inventory with the back-end “Fulfilling”servers 400, 500; retrieval of entitlements, i.e., a user's securityprofiles, and report pick list information, i.e., data for user reportcustomization options, from the system Order Entry server 280; thetransmission of report responses or messages to the Dispatcher server 26(FIG. 6); the maintenance of the reporting databases; and, themanagement of metadata used for displaying reports. In the preferredembodiment, the RM server 250 employs a Unix daemon that passivelylistens for connect requests from the GUI client applications and otherback-end servers and deploys the TCP/IP protocol to receive and routerequests and their responses. Particularly, Unix stream sockets usingthe TCP/IP protocol suite are deployed to listen for client connectionson a well-known port number on the designated host machine. Clientprocesses, e.g., report requester 212, desiring to submit requestsconnect to RM 250 via the dispatcher 26 by providing the port number andhost name associated with RM 250. For particular back-end server 400providing priced reporting data, a Talarian smart socket connection 254is provided. Request messages received by the RM server are translatedinto a “metadata” format and validated by a parser object built into areport manager proxy 250′ that services requests that arrive from theGUI front-end. If the errors are found in the metadata input, the RM 250will return an error message to the requesting client. If the metadatapasses the validation tests, the request type will be determined anddata will be retrieved in accordance with the meta data request afterwhich a standard response will be sent back to the requesting client. Asshown in FIG. 6, interface sockets 252 are shown connecting theDispatcher server 26 and the RM server 250 and, other socket connections254, 256 are shown interfacing with respective back end servers 400 and500. In one embodiment, server 400 provides a customer's priced billingdata through a Talarian smart socket messaging interface 254 to theReport Manager. Particularly, as described in commonly owned, co-pendingU.S. patent application Ser. No. ______ (COS-97-093), a back-end billingmainframe application known as the StarODS server provides such pricedcall detail data. Additionally, as shown in FIG. 6 and described incommonly owned, co-pending U.S. patent application Ser. No. ______(D#11567), the contents and disclosure of which are incorporated byreference as if fully set forth herein, call detail data is FTP'ddirectly to the Inbox Server and a message is sent to the report managerserver 250 from the Traffic View server (“TVS”) 500. Although not shownin FIG. 6 it should be understood that the RM 250 server can managereporting data for customer presentation from other back-end and legacyservers including, e.g., Broadband, Toll Free Network Management, andEvent Monitor servers, etc. in order to present to a customer thesetypes of network management and reporting data.

The report manager server additionally utilizes a database 258, such asprovided by Informix, to provide accounting of metadata and user reportinventory. Preferably, an SQL interface is utilized to access storedprocedures used in processing requests and tracking customer reports. Avariety of C++ tools and other tools such as Rogue Wave's tools.h++ areadditionally implemented to perform metadata message parsing validationand translation functions.

The Report Manager server 250 additionally includes the schedulinginformation, however, a report scheduler server component passes reportrequests to the back-end fulfilling servers 400, 500 at the scheduledtimes.

Particularly, the Report Scheduler (“RS”) server component 260 is, inthe preferred embodiment, a perpetually running Unix daemon that deploysthe TCP/IP protocol to send report requests to the back-end fulfillingservers such as the StarODS server 400, TVS server 500, and receivetheir responses. More particularly, the RS server 260 is a Unix serverprogram that is designed to handle and process report requests to thefulfilling servers by deploying Unix stream sockets using the TCP/IPprotocol suite, sending the request for customized reports to clientconnections on a well-known port number on the designated host machine.As shown in FIG. 6, interface socket connections 264, 266 are showninterfacing with respective back end servers 400 and 500. In the case ofpriced billing data from StarODS 400, report requests are published bythe RS server 260 to a pre-defined subject on the Talarian Server. Whenhandling other incoming messages published by back end servers usingTalarian SmartSockets 4.0, another daemon process is necessary that usesTalarian C++ objects to connect their message queue and extract allmessages for a given subject for storage in a database table containedin database 263. Each message includes the track number of the reportthat was requested from the fulfilling server.

From the report requestor interface, the user may specify the type ofreporting, including an indication of the scheduling for the report,e.g., hourly, daily, weekly or monthly. For priced data the user has theoption of daily, weekly, or monthly. For real-time, or unpriced data,the user has the option of hourly, daily, weekly or monthly. The reportscheduler interface additionally enables a user to specify a pager orE-mail account so that an e-mail or pager message may be sent toindicate when a requested report is in the Inbox server 270.

As shown in FIG. 6, the report scheduler server 260 interfaces directlywith the Report Manager server 250 to coordinate report requestscheduling and processing. It should be understood that the respectivereport management and scheduling functions could be performed in asingle server.

The Inbox Server component 270 serves as the repository where thecompleted user report data is stored, maintained, and eventually deletedand is the source of data that is uploaded to the client user via thedispatcher over a secure socket connection 272 between the Web serverand the browser. It is also a Unix program that is designed to handleand process user requests submitted in meta data format using anInformix database. Once report results are received from the StarODS 400and TVS 500 and any other back-end or fulfilling servers (not shown),the Report Manager server 250 communicates the corresponding reportmetadata to the Inbox server 270 over socket connection 274 as shown inFIG. 6. The metadata will be stored in the Inbox server database 273along with the report results. Thus, if the meta data is required to bechanged, it will not interfere with the information needed to displaythe reports contained in the Inbox. Additionally, as shown in FIG. 6,the Inbox server interfaces with the report scheduler to coordinateexecution and presentation of reports.

The StarOE server 280 is the repository of user pick lists and userreporting entitlements as shown in database 283. Particularly, it isshown interfacing with the Inbox server 270 and report scheduler servers260. The Report Manager does not interface with or contain metadata forStarOE. It will, however, include information in the report metadatathat will tell the Report Requestor it needs to get information (i.e.,Pick Lists) from StarOE server 285.

A common database may be maintained to hold the common configurationdata which can be used by the GUI applications and by the mid-rangeservers. Such common data will include but not be limited to: customersecurity profiles, billing hierarchies for each customer, generalreference data (states, NPA's, Country codes), and customer specificpick lists: e.g., ANI's, calling cards, etc. An MCI Internet StarOEserver will manage the data base for the common configuration of data.

With regard to the front-end client GUI components, the above-mentionedInbox client application 210 functions as an interface between theclient software and the Inbox server 270 for presenting to the customerthe various type of reports and messages received at the Inbox includingall completed reports, call detail, and marketing news messages.Preferably, the messages for the user in the inbox are sorted by type(report, call detail, alarms) and then by report type, report name,date, and time.

Particularly, the Inbox client application uses the services of thebackplane (FIG. 3) to launch other applications as needed to processreport messages. The inbox will also use the services of the data exportobjects to provide a save/load feature for inbox messages, and, is usedto provide a user-interface for software upgrade/download control. Inboxmessages are generated by the versioning services of the backplane;actual downloads will be accomplished by a request through the inbox.

In the preferred embodiment, the inbox client is able to receiveinformation on multiple threads to allow a high priority message to getthrough even if a large download is in progress. Typically, the browseris configured to allow more than one network connection simultaneously,i.e., the polling thread on the client uses a separate connection tocheck for new messages, and starts a new thread on a new connection whena new message is detected. In this way, multiple messages may bedownloaded simultaneously.

The Report Requestor application 212 is a GUI Applet enabling userinteraction for managing reports and particularly includes processessupporting: the creation, deletion, and editing of the user's reports;the retrieval and display of reports based on selected criteria; thedisplay of selected option data; and the determination of entitlementswhich is the logical process defining what functionality a user canperform on StarWRS. In the preferred embodiment, the Report requestoradditionally enables a user to specify the frequency of reportgeneration, e.g., periodically, or as “one-shots” to be performed at alater time. As described herein, the report scheduler service maintainsa list of requested reports for a given user, and forwards actual reportrequests to the appropriate middle-tier servers at the appropriate time.Additional functionality is provided to enable customers to manage theirinventory, e.g., reschedule, change, or cancel (delete) report requests.

In the preferred embodiment, the report requestor utilizes the platformclient JAVA code to communicate with the report manager server. Tocommunicate with the StarOE for user security, hierarchy, paging ande-mail, etc. the Report Requestor uses StarOE client Java code. ReportRequestor JAVA applets implementing the above-described report requesterfunctionality, are downloaded to the customer's workstation in the formof a cab file after initial login.

The Report Viewer application 215 is a GUI Applet enabling a user toanalyze and display the data and reports supplied from the fulfillingservers such as StarODS 400, Traffic View (“TVS”) 500, and other systemssuch as Broadband and toll free network manager. Particularly, theReport Manager 250 includes and provides access to the metadata which isused to tell the Report Requestor what a standard report should looklike and the “pick-list” options the user has in order for them tocustomize the standard report. It is additionally used to tell theReport Viewer client how to display the report, what calculations ortranslations need to be performed at the time of display, and whatfurther customization options the user has while viewing the report. Itadditionally includes a common report view by executing a GUI appletthat is used for the display and graphing of report data andparticularly, is provided with spreadsheet management functionality thatdefines what operations can be performed on the spreadsheet includingthe moving of columns, column suppression, column and row single andmultiple selection, import and export of spreadsheet data, printing ofspreadsheet, etc. It is also provided with report data managementfunctionality by defining what operations can be performed on the datadisplayed in a spreadsheet including such dynamic operations as sortingof report data, sub-totaling of report data, etc. Furthermore, thereport viewer 215 is provided with functionality enabling theinterpretation of Meta Data; and, functionality enabling communicationwith the Backplane (FIG. 3). The Report Viewer application 215additionally accepts messages telling it to display an image or textthat may be passed by one of the applications in lieu of report data(e.g., Invoice, Broadband report, etc.)

All reporting is provided through the Report Viewer interface whichsupports text displays, a spreadsheet, a variety of graphic and charttypes, or both spreadsheet/graph simultaneously. The spreadsheetpresentation allows for sorting by any arbitrary set of columns. Thereport viewer 215 is launched from the inbox client 210 when a report isselected.

By associating each set of report data which is downloaded via the Inboxserver 270 with a “metadata” report description object, reports can bepresented without report-specific presentation code. At one level, thesemetadata descriptions function like the catalog in a relationaldatabase, describing each row of a result set returned from the middletier as an ordered collection of columns. Each column has a data type, aname, and a desired display format, etc. Column descriptive informationwill be stored in an object, and the entire result set will be describedby a list of these objects, one for each column, to allow for a standardviewer to present the result set, with labeled columns. Nesting thesedescriptions within one another allows for breaks and subtotaling at anarbitrary number of levels.

The same metadata descriptions may be used to provide common data exportand report printing services. When extended to describe aggregationlevels of data within reporting dimensions, it can even be used forgeneric rollup/drilldown spreadsheets with “just-in-time” data access.

The metadata data type may include geographic ortelecommunications-specific information, e.g., states or NPAs. Thereport viewer may detect these data types and provide a geographic viewas one of the graph/chart types.

Referring now to FIG. 7, the traffic view system (“TVS”) 500 of thepresent invention comprises a Traffic View Server 550 which functions tostore network call detail records (CDRs) and statistics, generatereports and deliver reports and/or call detail to the customer via theStarWRS Web Reporting System, and, supplies on-line customer access tocall detail and hourly statistics that aid the customer in Networkmanagement, call center management and customer calling patternanalysis. For real time (unpriced) data, statistics are generated forthe following totals: minutes, attempts, completes, incompletes, other,dto (direct termination overflow), short calls, didn't wait, didn'tanswer, tcc, and equipment failures.

The process by which the TVS server 550 gets data is now explained ingreater detail with reference to FIGS. 7 and 8. As shown, call recordsare created by a network switch 501. An AP (Adjunct processor) orStorage and Verification Elements (“SAVE”) platform 502 is co-locatedwith each switch and receives all the call records from the switch assoon as possible after a call disconnects. The AP/SAVE sends all thecall records to a (Network Information Concentrator (NIC) 503 whererecords are grouped together and those groupings numbered for a moreefficient network utilization. If the NIC determines that it is missinga gap in the numbers, it will request the AP/SAVE resend that group ofdata to ensure that no data is lost. Should the NIC be unavailable toreceive data, the AP/SAVE queues the data for later delivery. The NIC503 receives all calls from all switches as soon as possible after acall has disconnected (hangs up) and distributes records to clients thatmatch a certain criteria.

A generalized statistics engine (GSE) component 504 receives all recordsthat are considered to be a toll free (800/8xx, etc) call from the NICand also employs the same sequencing of groups of records to ensure thatno data is lost. Should the GSE be unavailable, the NIC will queue thedata for later delivery. The GSE component 504 further filters toll-freecalls to only process calls that match a subscriber list which ismaintained by an order entry OE process on the GSE (not shown) thataccepts add & delete requests from TVS via a messaging interface 507 asshown in FIG. 7. The GSE component then formats the CDRs, i.e., enhancesthe call records, from the form as originally provided at the switch,into a normalized form to allow for a common record format regardless ofthe type of switch that created the record, or the exact call recordtype. For example, different network switches generate different calldetail records, e.g., call detail record, enhanced call detail records,etc., which denote differences in toll-free services and features. Thistype of call detail record generated by GSE component is herein referredto as a TCR (Translated Call Record).

Groups of TCRs are sent from the GSE to TVS via TCP/IP. When TVS hassafely stored that record it sends an acknowledgment to the GSE 504 sothat the GSE may dispose of the group. Should TVS not be available toreceive data, GSE queues data to be sent later.

As shown in FIG. 7, in the preferred embodiment, initial customerprovisioning occurs at either the Corporate Order Entry system 223(CORE) or the StarOE server 285 component of MCI Interact. As shown inFIG. 9, CORE 223 transmits daily to the TVS server 550 via Network DataMover (NDM) files which comprise information about new reports for TVSto create, and where to send those reports, e.g., FAX, E-Mail, or USMail. In the NMCI Interact TrafficView Server 550, a CORE FEED process523 provisions reporting order and profiles into a reference database551, and sets up scheduled reports to work on the next boundary, e.g.,hourly, daily reports at midnight the next complete day, weekly reportsat the end of the next week, monthly reports at the end of the month,etc. If this report requires Call detail records, as opposed toaggregated data, a CDR database is selected based on weighted values forthe existing database. If a request contains a toll-free number that hasnot been provisioned with the GSE, a GSE_OE process 524 is invoked toforward the order, e.g., toll-free number, from the reference databaseonto a DEC Message Queue™ “DMQ” 526 a. A GSE_OE_SEND process 527 isinvoked to keep a TCP/IP socket open to the GSE process so that thepending order may be forwarded to the GSE 504 via a TCP/IP interface.Once the order has been provisioned in GSE the GSE may start to collectCDRs based on the requested toll-free number. In response, the GSE willinvoke the GSE_OE_SEND process 527 to send an order response to a DMQ526 b, where it will be accessed by the GSE_OE process 524. The GSE_OEprocess 524, in turn, will confirm that the number has been provisionedwithin the TVS server and will update the reference database accordinglyby removing the order from a pending order list. Invocation of theGSE_OE process and the GSE_OE_SEND process enables tracking of newcustomer orders, i.e., new toll-free network numbers for which CDR datais to be collected.

As further shown in FIGS. 7 and 9, in the preferred embodiment, requeststo enable TrafficView customers are received in real-time from StarOE285 via TCP/IP. Generally, StarOE specifies what general categories ofreports can be requested for a given nMCI Interact subscriber. Thesecategories include: 1) reports that only require data aggregation; 2)reports that require call detail records to be collected; and 3)real-time monitor (RTM) reports. This is provisioned into the referencedatabase 551 for future verification of requests from the nMCI Interactplatform. If a request contains a toll-free number that has not beenprovisioned with the GSE, a subscription request is sent to the GSE 504via the GSE_OE and GSE_OE-SEND process to start collecting TrafficViewdata pertaining to that toll-free number. This request is sent byplacing a request onto the DMQ queue 526 a, and the GSE_SEND_OE process527 then forwards this request to the GSE 504 via a TCP/IP interface. Inthe preferred embodiment, the content and format of an “order entry”message generated by the TVS server for requesting unpriced traffic datafrom the GSE is provided in Appendix H. In accordance with thismessaging, the GSE selects all TCR's for TVS enabled customers andplaces them in a SAVE storage queue, e.g., Versant or Talarian, forsubsequent distribution to the TVS server.

As further shown in FIG. 7, an input feed from the calling area databasecomponent 508 (“CADB”) provides the TVS server 550 with reference dataincluding state and country information for mapping NPA/NXX (NumberingPlan Area/Number Exchange) to city name and state code, and, for mappingcountry codes to country names. Data is transported from the CADBdatabase 518 to the TVS server via a network data mover (“NDM”) or FTPvia interface 519.

A further input feed from the Global Information Repository “GIR”component 511 provides the TVS server with International toll-freenumber terminations on a periodic basis.

From the circuit order management system (“COMS”) component 515, TVSreceives three NDM feeds: 1) a Trunk Type Master feed 516 used inUn-priced Reporting to map enhanced voice service/dedicated access line(EVS/DAL) information to specific service locations; 2) an automaticnumber identification (“ANI”) feed 517 also used in Unpriced Reportingto map EVS/DAL information to specific service locations; and, 3) aswitch mapping feed 518 to map the switch ID (per Network controlsystem) to the billing representations of the same switch.

As further shown in the FIG. 7, unpriced data collection process beginswith the placement of an order for unpriced reporting with thecustomer's account team. Specifically, the account team places the orderin real time using an ordering system component. In a periodic process,this order information is transmitted to OEHubs 224, e.g., via e-mailwhich later inputs the necessary service and reporting flags to theStarOE component 285, via messaging interface 226. The OEHubs 224further adds new customers to the corporate order entry (“CORE”) systemcomponent 223, which provides customer billing hierarchy informationused by the StarWRS system. The new customer hierarchy information isextracted by the CORE system 223, and is available for pickup by theStarOE server 285 via messaging interface 227.

The StarOE server 285 then messages the Traffic View Server 550 in realtime via TCP/IP that the number has been added for Unpriced Reporting.The TVS additionally messages the GSE component 505 in real time toimmediately initiate the collection of call detail for that number, aswill be described in greater detail herein. Due to latency inherent inthe fulfillment process, customers may select and receive daily reportsafter CDR collection begins.

In accordance with the invention, a wide variety of reports andreporting frequencies are available. In the preferred embodiment,reports are available in hourly, daily, weekly, and monthly frequencies.

Types of TVS reports that are available to customers include: Standardreports; Summary reports; Termination Reports; Exception reports; and,unpriced call detail. For example, Standard reports that may begenerated from stored Toll Free hourly statistics include, but are notlimited to: Summary by Toll Free Number and Hour which is available inthe following frequencies (Ad-hoc “A”, Daily “D”, Weekly “W”, andMonthly “M”); Summary by Toll Free Number and Date(A,D,W,M); Summary byToll Free Number and day of week (“DOW”) (A,W,M); Summary by Toll FreeNumber and Week (A,M); Summary by Toll Free Number and NPA (A,D,W,M);Summary by Toll Free Number, Service Location and Hour(A,D,W,M); Summaryby Toll Free Number, Service Location and Date (A,D,W,M); Summary byToll Free Number, Service Location and DOW (A,W,M); Summary by Toll FreeNumber, Service Location and Week (A,M); Summary by Service Location andHour (A,D,W,M); Summary by Service Location and Date (A,D,W,M); Summaryby Service Location and DOW (A,W,M); Summary by Service Location andWeek (A,M); Summary by Service Location, Toll Free Number and Hour(A,D,W,M); Summary by Service Location, Toll Free Number andDate(A,D,W,M); Summary by Service Location, Toll Free Number and DOW(A,W,M); Summary by Service Location, Toll Free Number and Week (A,M).The Toll Free Summary Reports generally comprise three sections:Summary, Incomplete Call Analysis, and Network Customer Blocked Analysis(other category breakdown). The Termination Summaries include threetypes of termination reports: Toll Free by Location, i.e., showingtermination summary and incomplete call analysis by service location fora specific Toll Free number; By Location, i.e., by service locationacross all Toll Free numbers terminating to the same service location;and, Location by Toll Free, i.e., for a specific service location, showseach Toll Free number terminating to this location. The originatingNPA/Country Code summary reports provide information by NPA and Countryfor each Toll Free number attached to the report.

Additionally available are what are called Call Detail ExceptionReports/images which provide reporting information pertaining to thefollowing: Completion Rate and Retry (A,D,W,M); Completion Rate andRetry with Queue Abandonment (A,D,W,M); Lost Caller and Retry (A,D,M);Lost Caller and Retry with Queue Abandonment (A,D,M); Most FrequentCalling Numbers (A,D,W,M); Most Frequent Calling NPA/NXX (A,D,W,M); MostFrequent Calling Country (A,D,W,M).

The nMCI Interact Exception reports (images) includes: Completion Rateand Retry (A,D,W,M); Completion Rate and Retry with Queue Abandonment(A,D,W,M); Lost Caller and Retry (A,D,M); Lost Caller and Retry withQueue Abandonment (A,D,M); Most Frequent Calling Numbers (A,D,W,M); MostFrequent Calling NPA/NXX (A,D,W,M); and, Most Frequent Calling Country(A,D,W,M). The nMCI Interact Exception reports (data) includes: CallDetail by Originating ANI (A,D,W,M); Call Detail by ID Code (A,D,W,M);Call Detail by NCR Indicator (A,D,W,M); Call Detail by Originating State(A,D,W,M); Call Detail by Disposition (A,D,W,M); Call Detail by ServiceLocation (A,D,W,M); Payphone Summary (A,M). Downloadable nMCI interactCall Detail reports includes Traffic view call detail (available asad-hoc and daily) and Outbound traffic view call detail data (availableas ad-hoc, daily and weekly).

As mentioned, via TCP/IP messaging, the TVS system 550 receives arequest in real-time from the nMCI Interact StarOE component 285 tobegin collecting call detail records for a particular TVS/Unpricedreporting customer, which number had been previously assigned during theorder entry process. When a customer discontinues Unpriced Reporting fora number, this information is entered in StarOE tables where it isstored for a predetermined period subsequent to termination of thenumber. After the predetermined period of time, e.g., seven days, thenumbers scheduled for service deletion are passed to TVS via TCP/IPconnectivity in real time. After receiving this information, TVSinstructs the GSE 504 in real time to stop collecting CDRs for thesenumbers.

FIG. 10 illustrates a generalized block diagram detailing the internalTVS data acquisition processes. As shown in FIG. 10, a TVS server“GSE_TCR_RCVR” process 564 receives a group of TCR records from the GSEcomponent 504. The GSE_TCR_RCVR process 564 inserts that group into aDMQ (DecMessageQueue) queue 553 a that provides a guaranteed messagedelivery. Upon successful storing of a record into the DMQ queue 553 a,the GSE_TCR_RCVR process 564 sends an acknowledgment to the GSEcomponent 504 so that it may delete that group. If TVS fails toacknowledge this group after a predetermined timeframe, the GSEcontinues to resend this group until an acknowledgment is received. TheTCR_DISTRIB process 566 reads groupings of records and distributes arecord based on the toll-free number associated with that record in thefollowing manner:

First, as the reference database 551 contains information on whichtoll-free number belongs in which CDR database associated with the TVSserver, records are grouped for each CDR database 561 a, 561 b, . . . ,561 n, to which they belong. The reference database 551 additionallyflags which numbers are to have statistics collected for them. Thus, anadditional group of records is created and may be routed to a DMQ Queue553 b which inputs these records into a statistics “stats” counterprocess 570 for statistics processing, as will be described in greaterdetail herein. When all the records in the group have been read, eachgroup is written to it's DMQ queue 554 a, 554 b, . . . , 554 nassociated with its destination database CDR Database 561 a, 561 b, . .. , 561 n. For instance, via a TCR Poster process 555 a, recordsdestined for CDR database 561 a are forwarded from the DMQ Queue 554 a.Particularly, each CDR poster process 555 a, 555 b, . . . , 555 n readsdata from it's corresponding DMQ Queue and formats & stores thoserecords in their database.

With further regard to the stats counter 570 shown in FIG. 10, TCRs arerolled up into statistics records. Specifically, the stats counter 570keeps counts of the following: summary information about each toll freenumber for an hour; summary information about each toll free number andtermination for an hour; and, summary information about each toll freenumber and origination NPA for an hour. These statistics are kept inmemory for a pre-determined amount of time, e.g., one hour. As matchingrecords come in, statistics are updated. At the end of the time period,these records are written to the statistics database 571, andparticularly high speed electronic data drives.

The statistics that are gathered for each subscriber's toll-free numberin the TVS system of the invention include: total completions, totalcall duration, total attempts, total switch control call, total NetworkControl System (NCS) blocked, total NCS rejected, total network blocked(all routes busy), total supp code blocked, and out-of-band blocked. Thesummary table processing algorithm in Appendix I details the collectionof these statistics by the GSE and the TVS summary table processing.

Additionally, statistics gathered for NP table processign include:originating NPA, total attempts per NPA, total calls completed (tcc) perNPA, total call not delivered (blocked) per NPA, total attempts forInternational Originations, tcc for International Originations (“IO”),total calls not delivered (blocked) for IO.

Additionally, call statistics for terminations inlcude: terminationtype, termination address, total completions, total call duration, andcall dispositions indicating the cause of an incomplete call including:total short calls, total didn't write, and total didn't answer.

With more particularity regarding the statistics database design, and,in further view of FIG. 10, the stats_counter 570 contains processesthat read TCR's from a DMQ queue, and create statistics records forinput to “c_tables” in the statistics database 571.

Appendix I depicts the algorithms implemented in TVS stats_counterprocess 570 for generating statistics data tables so that TCR recordsmay be processed in batches. As shown, the processes include: a summarytable process which process generates statistics for call summary data;a NPA table process; Country table process and Termination tableprocess. The stats_counter 570 enables multiple processes to be run atthe same time on the same machine. To allow an arbitrary number ofStats_Counter processes, the stats databases are organized as a seriesof configurable tables, e.g., “C_Tables” 572, which are temporary tablesthat the stats counters first insert records to: These tables areidentical to normal statistics tables with the exception that theyinclude a field for the date in them. In accordance with the provisionof C_tables, a pending_stats_list table and stats_table_usage_list tableare used to keep track of what data is in the C_tables, and to drive themovement of data from the C_tables to a more permanent database tables574.

Particularly, when the stats_counter process 570 starts, it performs acheck of the set of “c_tables” by inserting its process name in theused_by_process field of the stats_table_usage_list table. If thestats_counter process unexpectantly dies, it reclaims the tablespreviously used by searching the stats_table_usage_list for tablesmarked with it's process name. The stats_counter process adds an entryinto the pending_stats_list every time it creates stats for a new day.The usage_flag is initially set to “1” in that table. At the top of thehour, for example, the stats_counter processes marks all of theusage_flag entries to “2”, and modifies the value of the used_by_processfield in the stats_table_usage_list to “MOVER”. The stats_counterprocess then searches the stats_table_usage_list for another set oftables to use for the next hours counting. If the stats_counter processcannot find a set of tables, it aborts. To avoid this, there is extrasets of “c_tables” configured with entries in thestats_table_usage_list.

Table 1 depicts an example pending_stats_list table which comprises adirectory of what the stats_counter is working on, or finished with.Each record represents a name of a c_table that contains statistics, anddates that are contained in this c_table. The report generator process,and on-line access use this table to determine if there is any data inthe c_tables that they may be interested in, and what the table name is.The Stats_counter processes insert records into this table, anddata_mover processes 573, shown in FIG. 10, remove entries from thistable. TABLE 1 pending_stats_list table description Column Type Usagedata_month_day Integer date in form YYYYMMDD e.g. 19960822 table_typeCharacter type of statistics data “SUMMARY” (16) “TERMINATION” “NPA” or“COUNTRY” usage_flag Tinyint 1 - table in use by stats_counter 2 - tablecontains data ready for access table_name Character exact name of tablein use e.g. (16) “C_NPA_03”

Table 2 depicts an example stats_table_usage_list table which comprisesa list of all the c_tables that are configured and used by thestats_counter processes and data_mover processes to allocate tablesamongst themselves. The number of records in this table remains static.Stats_counter processes 570 update the “used_by_process” field withtheir process name when they are in control of that table. At the top ofthe hour, they may change the used_by_process to “MOVER”, and attempt tofind another table that is unallocated. The movers change theused_by_process name to “NONE” when they have completed moving data fromthat c_table. TABLE 2 stats_table_usage_list table description ColumnType Usage table_type character type of statistics data “SUMMARY” (16)“TERMINATION” “NPA” or “COUNTRY” table_name character exact name oftable in use e.g. (16) “C_NPA_03” used_by_process character process nameof the stats_counter or (16) “MOVER” to indicate what processes arecurrently using this table. “NONE” if this table is unused.

In the preferred embodiment, there are four types of movers arecurrently configured to run: NPA, summary, country, and termination.Each type of mover looks in the pending_stats_list for the name of the“c_table” of the same type with a usage_flag of “21”, for instance, andthe earliest date. The mover then transfers the data for this date fromthe “c_table” to appropriate the permanent table. When the data transferis finished, the matching record in pending_stats_list is deleted. Ifthere are no more entries for this “c_table” in pending_stats_list, themover process takes the precautionary step of searching the “c_table”for additional data that was not noted in pending_stats_list. Entriesare then added to pending_stats_list for any data found in the“c_table”. If no additional data is found, used_by_process instats_table_usage_list is changed from “MOVER” to “NONE” for this“c_table”.

The interaction between StarWRS web-based reporting system and TVSsystem 550 will now be explained in greater detail with respect to FIG.11. In the preferred embodiment, reports may be triggered by twopossible sources: Scheduled report setup by a CORE order; and, real timereport requests as forwarded from the report request/Report ManagerServer 250. The report generation process is hereinafter described withrespect to real-time reports from the StarWRS system.

As mentioned, requests are received in real-time from the Report ManagerServer 250 which either passes on-demand reports from an end-user, orreports that it has internally scheduled via Report scheduler server260. In the TVS server 550, a report manager proxy process 250″ gathersinformation about the reports to be generated from the referencedatabase 551 by determining whether the report request may be fulfilledby statistics processing, or the CDR's. If CDR's are needed, adetermination is then made as to which database contains the necessarydata. Additionally determined is whether the needed CDR data to fulfillthe request spans a long period of time, e.g., several days. Once thesedeterminations are made, the requests are sent from the report managerproxy process 250″ to the appropriate DMQ queue 554 a, 554 b, . . . ,554 n, or 553 b where they are queued up for report generation.

For the scenario requiring generation of call detail data reports, i.e.,those requiring Call detail records, the destination of the report,e.g., StarWRS Inbox server 270, fax, U.S. mail, etc., is determined fromthe reference database 551. Then, the requested data is gathered basedon the metadata request, analyzed, and formatted by variouscorresponding detail report generator processes indicated in FIG. 11 asprocesses 559 a, . . . , 559 n. Although not shown in FIG. 11, it shouldbe understood that reference data that originates from CADB and COMS maybe necessary to complete these reports. Furthermore, although not shown,the TVS server is provided with an additional set of queues and reportgenerator processes for each of the CDR processing to allow longerreports to not interfere with shorter reports.

In the detail report generator processes, the data is formatted in acomma separated value (CSV) format and are input to a finished reportfiles database 582 whereupon, an inbox server interface process 583 FTPsthe report to the nMCI Interact Inbox Server 270. The Inbox interfacewill particularly input the completed report to the pre-defineddirectory in the Inbox database. Particularly, the Inbox is notified viaTCP/IP that the report is complete by the Inbox Interface process andthat the appropriate metadata is available for report presentation viathe report viewer.

If the requested report is destined for MCI Mail delivery (Fax, Mail, USMail): then the data is formatted with headers, page breaks, linenumbers into a report that is saved to a file. The report is then sentto an Internet Gateway 279, e.g., the MCI Mail Internet Gateway directlyfrom the detail report generators 559 a, . . . , 559 n for delivery byMCI Mail. Once the file is successfully sent it is deleted, thusallowing for report generation to continue when the MCI Mail InternetGateway is not available.

An identical process is implemented for those customer report requestsfor aggregate data, i.e., statistics. However, the data that is gatheredand analyzed is retrieved from a summary report generator process 581which retrieves the requested report data from the statistics database571 upon a receipt of a report request from the DMQ 553 b.

As described herein, when the user requests call detail for a particularperiod of time, this request is translated by the StarWRS component intoa metadata file which is sent to TVS in the manner described herein.Users schedule reports for execution using the Report Scheduler inStarWRS in the manner as described in co-pending U.S. patent applicationSer. No. ______ (D#11050). When the user has completed report selection,modifications and scheduling, the StarWRS Report Scheduler component 260creates a metadata message comprising this information which file ispassed to TVS in real time. The TVS then uses this file to formulate aquery and runs the report for the scheduled time period.

After TVS runs the report, TVS sends the report to the Inbox servercomponent 270 of StarWRS immediately after they are completed.

An overview of the report request/scheduling process 600 implemented byStarWRS web-based reporting component 200 will now be described hereinin view of FIGS. 12(a)-12(d) as follows:

As shown in the process flow diagram of FIG. 12(a), a user firstestablishes communication with the DMZ Web server at step 602 and logson to the nMCI Interact system by entering the user's name and passwordonto a logon dialog box, as indicated at step 604. Then, at steps606-608, an application running on the backplane directs a “ValidateUser Message” common object to the StarOE server 280 via the web serverand dispatcher servers (FIG. 2) to direct the StarOE server 280 toperform security validation and authenticate the user ID and password inthe manner as described in commonly owned, co-pending U.S. patentapplication Ser. No. ______ (D#11043), entitled AUTHENTICATION ANDENTITLEMENT OF WEB BASED DATA MANAGEMENT PROGRAMS, the contents anddisclosure of which is incorporated by reference herein. It isunderstood that all communication to the StarOE server is via TCP/IPwith a Unix process listening on a known TCP port. The StarOE serveracts as a proxy when messages are sent from the Dispatcher server 26 andsupports synchronous transactions. All data and security information isaccessed by direct queries to a StarOE server database 283, such asprovided by Informix. Once a user is logged on, the Web Server 24 (FIGS.2 and 6) requests a current list of authorized applications from theStarOE server 285 as indicated at steps 608 and 610. Particularly, asdescribed in co-pending U.S. patent application Ser. No. ______(D#11042), the contents and disclosure of which is incorporated byreference herein, a “Get User Application Request” message iscommunicated to the StarOE server via the backplane from the reportrequestor which queries the Informix database to obtain a list ofauthorized applications, i.e., services, for the user and whichdetermines which buttons on the home page are active, thus controllingtheir access to products. This information is downloaded by a GUI appletthat is executed via the Backplane (FIG. 3) and incorporated into thehome page that is presented to the user as indicated at steps 612-614.An exemplary home page screen display 80 is shown in FIG. 4 whichprovides a list of icons 70 representing the possible options availableto the user according to that customer's entitlements.

Appendix H of co-pending U.S. patent application Ser. No. ______(D#11050) provides the format and content of the nMCI Interact commonobjects downloaded to the Report Requestor client application to enableweb-based reporting. As shown in above-referenced Appendix H, the ReportRequestor first asks for common objects for a user's default timezone,language and currency. The Report Requestor objects are invoked toretrieve from StarOE the various customer entitlements relating tosecurity, geographical hierarchy, billing hierarchy, and paging ande-mail notification, as further shown in Appendix H.

As further shown in FIG. 12(a), the steps 615 and 616 indicate theselection and presentation of the Report Requestor display whichpresents the reporting options to a user in accordance with that user'sentitlements as determined at previous step 610. It should be understoodthat in the preferred embodiment, the icons for applications the userhas security access to are shown bolded. Thus, for a customersubscribing to nMCI Interact Unpriced Reporting, an Unpriced Reportingicon is automatically enabled when the home page appears.

At step 614, upon selection of a Report Requestor icon 76 from the homepage screen display 80 of FIG. 4, a StarWRS report requester web page ispresented to the customer. The backplane object allows the user accessto the Report Requestor front end if the user is so authorized. As shownat step 615, a client unpriced reporting application is downloaded tothe customer who is presented with the unpriced reporting dialog screen(not shown). It is from this screen that the user is presented withunpriced reporting options to view/retrieve completed reports via theStarWRS Inbox, as indicated at step 620 (FIG. 12(b)), or create a newreport or, modify an existing unpriced call detail data report.

Particularly, from this dialog screen, the user is enabled to edit anexisting report maintained in the report manager inventory, generate anew report, copy an existing report, or delete an existing report. Whencreating a new report or editing an existing report, the user may enterthe desired reporting options including: 1) the report product includingtoll-free, MCI Vision, and MCI Vnet options; 2) the report categorywhich includes options for: analyzing traffic, call center, call detail,checking calling frequencies, financial, marketing, monitoring usage,and telecommunications categories for toll-free, Vnet and Visioncustomers; 3) the report type which includes unpriced call detail dataor traffic data options; and 4) a report direction and which includesinbound, outbound, or both directions. Referring to the flow chart ofFIG. 12(b), user selection of the report product, report category,report type, and report direction, is indicated at step 620.Additionally, at step 625, the user may select the report formatassociated with a reporting category.

In accordance with the user report selections, if a report had alreadybeen created and maintained in the report manager inventory (database),it will be displayed in a report inventory field. Referring back to FIG.12(b), at step 626, a determination is made as to whether an existingreport from inventory is selected. If an existing report is not selectedthen the user is prompted to generate a new report according tocustomization options that the user is entitled for the selected reportproduct, category, type, etc., as indicated at step 630. If an existingreport is selected at step 626 based on the report product, category,type, etc., then the user is prompted at step 628 to select from amongthe following options: a report edit option, as shown at step 635; areport delete option, in which case the selected report will be deletedat steps 638 and 639; and, a report copy option, in which case anexisting report will be copied, e.g., for subsequent editing, as shownat steps 640 and 641.

Whether creating a new report or editing an existing report, the user isenabled to select customization options as indicated at step 630, FIG.7(b) from a new dialog screen that is presented to the user showing allthe report customization categories for building a new report and/orediting an existing report. From this screen and related report buildingdialog boxes, all of the initial values for retrieving the MetaData,customization options and GUI builder options from the report managerserver 250 necessary to build (edit) a report are provided in accordancewith the user's entitlements. As described in greater detail inco-pending U.S. patent application Ser. No. ______ (D#11050), a user mayprovide the following customization and report builder options: generalcustomization options; layout customization options; accesscustomization options; hierarchy customization options; geographiccustomization options; and, notification customization options.

As mentioned above with respect to FIG. 6, the Report Requestor clientapplication 212 gains access to the Metadata stored at the ReportManager server 250 through messaging. Particularly, as hereinafterdescribed, a message generated by the Report Requestor in accordancewith the user request is first received by the report manager proxy250′. In the preferred embodiment, the report manager proxy comprises aset of tools in the form of reusable objects, preferably written in C++code, or the like. For example, a parser object tool is employed todecompose the Metadata messages sent by the report requester 212 tovalidate the message. If errors are found in the Metadata input, the RMwill return an error message to the requesting client. If the Metadatapasses the validation tests, the request type is then determined and theappropriate service will be invoked after which a standard response issent back to the requesting client.

The Report Manager 250 implements stored procedures to translate themessage, perform the request, and send the information back to theReport Requestor 212 which uses the metadata to determine what astandard report should look like, the customization options the userhas, and the types of screens that should be used for the variousoptions (i.e., single selection, multiple selections, etc.). It isunderstood that the selection of available standard template reports isbased on the user's entitlements.

The following list provides the types of requests that may be initiatedby the Report Requestor 212 and the responses performed by the ReportManager 250: 1) Get/Send report template list (GRTL/SRTL)—which requestretrieves the list of all standard report templates for all products andis used only to obtain general report information, e.g., report title,description, etc.; 2) Get/Send report template detail (GRTD/SRTD)—whichrequest retrieves the details of a specific standard report template; 3)Get/Send user report list (GURL/SURL)—which request retrieves the listof all user reports for the report format selected from a user reporttable and is used only as a request for general report information,e.g., report title, status, etc.; 4) Get/Send user report detail(GURD/SURD)—which request retrieves the details of a specific user'sreport; 5) Add report definition/Acknowledgment (ARD/ARDA)—whichrequests addition of a user-created report to a user report table. Ifthe report is a scheduled report, this request is also communicated tothe fulfilling server at the time the report is due; 6) Delete reportdefinition/Acknowledgment (DRD/DRDA)—which request deletes auser-created report from the user table; 7) Copy reportdefinition/Acknowledgment (CRD/CRDA)—which request creates a duplicationof the report the user is editing (other than the report title) andcreates a new report ID for it; 8) Update ReportingSchedule/Acknowledgment (URS/URSA)—which request updates the schedulinginformation on a report without having to send a Delete and Add request;and, 9) Get Pick List/Acknowledgment (GPL/GPLA)—which request enablesthe Report Requestor 212 to get a pick list provided by StarOE server.

In a preferred embodiment, as shown in Table 3, the interface messagesent to the RM server 250 from the report requestor via the Dispatcherserver 24 comprises a three to four character message acronym followedby request specific parameters. TABLE 3 Parameter Parameter AcceptableName Type Required Value Request 3 or 4 Yes Msg acronym Characters DataCharacters No parms . . .

Table 4 illustrates the interface message format returned by the RMserver 250. TABLE 4 Parameter Parameter Acceptable Name Type RequiredValue Response Char (4) Yes Msg acronym Error Code Char (4) Yes 0 = OKor error Data Char # No parms . . .

As shown in Table 4, the response message to be returned in Metadataformat preferably includes a four character message acronym followed byan error code. A successful request (or a request acknowledgment)generates a response with an error code of “0”. Additional data specificto the response follows this error code. If any server receives amessage which is not known, the response message will echo the messageacronym back along with an appropriate error code.

Appendix A provides a series of tables containing the content for eachmetadata message request that can be sent by the report requestor 212for each of the enumerated user requests, in addition to the content ofthe corresponding metadata message responses by the RM server 250. As anexample, when a user requests a list of all standard report templatesthat can be created for a specified product, category, and product type,e.g., toll free unpriced data, an example metadata format is as follows:

-   -   GRTL<PRODUCT=V,DATATYPE=D,DATACAT=U,IO=O>        where GRTL is the message name, the PRODUCT indicates the        product type, e.g., V=Vnet, C=CVNS, S=Vision, T=toll free,        F=Traffic view, etc. DATATYPE indicates the data type, e.g.        R=reports, D=call detail, etc., and DATACAT represents the        report category, e.g., P=priced, U=unpriced.

In the hereinafter described manner, the GRTL message is received by theStarWRS proxy server application 250′ to enable the RM server 250 toperform the query into the RM Informix database having the dataassociated with the request. Specifically, after selecting the ReportRequester from the browser or the Toolbar, a WRSApp object is launched.At its creation, the WRSApp object creates a DataManager object to guidethe data and which initiates a CommunicationManager object to manage allcommunication between the client and the server. TheCommunicationManager utilizes a RptManagerMsg object to create: 1) aGRTL; 2) a WRSCommWrapper for direct communication with the backend;and, 3) a WRSReportManagerUtilParser to format the data returned. Inresponse, the Report Manager creates a Dispatcher object, which containsthe business logic for handling metadata messages at the back-end andutilizes the services of a RMParser class. Upon determining that theclient has sent a valid message, the appropriate member function isinvoked to service the request. Upon receiving the message, the ReportManager creates the Parser object (RMParser) which takes the messageapart and invokes a validation object which validates the message.

In response to the GRTL message, the data returned by the Report Managerserver 250 for this particular request may include the following data inmetadata format as follows: SRTL<ERROR=0, REPORTS =<RptCategoryDescription1 =<RptTitle1.1, RptTemplateID1.1,RptCategoryType1.1>, <RptTitle1.2, RptTemplateID1.2,RptCategoryType1.2>>, <RptCategoryDescription2 =<RptTitle2.1,RptTemplateID2.1, RptCategoryType2.1>, <RptTitle2.2, RptTemplateID2.2,RptCategoryType2.2>>, ... <RptCategoryDescription#n=<RptTitle#n.n,RptTemplateID#n.n, RptCategoryType#n.n>, <RptTitle#n.n,RptTemplateID#n.n, RptCategoryType#n.n>>>wherein RptID# indicates a standard report template ID, RptTitle#indicates the standard report template title, RptCategory# indicates thereport category, e.g. Monitor Usage, Analysis Traffic, Historical,Executive Summary, Call Detail, etc.; and, RptDescript indicates thestandard report template description displayed to the user. Thus, foreach Report Template Category, there will be the list of reports witheach entry containing a Report Template Title, a Report TemplateDescription and the Report Template ID.

The SRTL message is sent from the StarWRS RM proxy server to the reportrequestor for presentation to the customer. Specifically, the SRTLresponse is built inside the esql wrapper function after obtaining thenecessary information through the stored procedure from the ReportManager Informix database. The Report Manager creates the RMServerSocketobject and sends the SRTL message back to the client.

To retrieve details of the standard report template, the GRTD requestmessage request is sent having content shown in the table in Appendix A.When specified, the Report ID field indicates an existing report that auser may wish to edit.

The SRTD response generated by the RM server is formatted in metadata asfollows: < Report Template ID=ID#, NODE1=<node level1, label value1,assigned unique screen identification1, >, NODE2=<node level2, labelvalue2, assigned unique screen identification2, <control ID2.1, fieldvalue2.1, data location2.1>, <control ID2.2, field value2.2, datalocation2.2>, <..,..,..>>, NODE#n=<node level#n, label value#n, assignedunique screen identification#n, <control ID#n.1, field value#n.1, datalocation#n.1>, <control ID#n.2, field value#n.2, data location#n.2>>

In the SRTD message, the MetaTreeData Label fields include such valuesas General, Report Name, Report Description, Scheduled Execution, etc.The MetaCtrlInfo MetaField Value fields may be blank or may contain theselection options available to the user. This information is taken fromthe report template database.

As another example, when a report request is submitted to retrieve afull list of user created reports from a user report table, i.e., atemplate list for a particular report product, category, and type, theexample metadata format is as follows:GURL<USERID=jeanvnet2,RPTTMPID=1,ENTPID=00022924, PRODUCT=T,DATACAT=U>with UserID and ReportTemplateID fields specified. Specifically, thisprocess entails invoking the Communication Manager object to communicatewith the RM server in order to obtain a SURL metadata message. TheCommunicationManager utilizes the RptManagerMsg object to create: 1) aGURL, 2) a WRSCommWrapper for direct communication with the backend,and, 3) a WRSReportManagerUtilParser to format the data returned. Theparser returns a hash table containing the User Report List. At the RMserver, the Report Manager creates an Dispatcher object that containsthe business logic for handling metadata messages at the back-end andutilizes the services of the RMParser class. Upon determining that theclient has sent a valid message, the appropriate member function isinvoked to service the request. The Report Manager, upon receiving amessage, creates a Parser object (RMParser) which takes the messageapart and invokes a validation object which validates the message.

In response to the GURL request, the data returned is taken from a userreport table in the RM server database. The generic SURL message inMetadata format returned by the RM server 250 includes the followinginformation: REPORTS = <UserRptCategory1 = <UserRptTitle1, UserRptID1,activeflag, report type, statusdate >>, <UserRptCategory2 =<UserRptTitle2, UserRptID2, activeflag, report type, statusdate>>,...<UserRptCategory#n = <UserRptTitle#n, UserRptID#n, activeflag, reporttype, statusdate>>>wherein for each user report category, there is a list of reports whereeach entry contains a UserRptID# indicating a user-defined reporttemplate ID, a UserRptTitle# indicating the user's report templatetitle, and a UserRptCategory# indicating the user report category.Specifically, the SURL response is built inside an esql wrapper functionafter obtaining the necessary information through a stored procedurefrom the Informix database. The Report Manager creates theRMServerSocket object and sends the SURL message back to the client.

To retrieve the details of a specific user's report, the GURD message issent having data as contained in the table shown in Appendix A.Specifically, when the user selects a report from the Inventory List onthe Report Requestor, a Communication Manager object is invoked tocommunicate with the RM server in order to obtain a SURD metadatamessage. The CommunicationManager object first utilizes theRptManagerMsg object to create: 1) a GURD metadata message, 2) aWRSCommWrapper for direct communication with the backend, and 3) theRSReportManagerUtilParser to format the data returned. The parserorganizes the data into a series of nodes which are utilized to createthe report builder tree on the report requestor customization screen.Later this data will be extracted from the node and used to constructthe screen related to the node. The Report Manager server creates theMCIDispatcher object which contains the business logic for handlingmetadata messages at the back-end and utilizes the services of theRMParser class. Upon determining that the client has sent a validmessage, the appropriate member function is invoked to service therequest. The Report Manager, upon receiving a message, creates theParser object (RMParser) which takes the message apart, invokes avalidation object which validates the message and builds a responseinside the esql wrapper function after obtaining the necessaryinformation through the stored procedure from the Informix database. TheReport Manager creates the RMServerSocket object and sends the SURD/SRTDmessage back to the client. The responsive SURD metadata messagecorresponding to a retrieve user report detail (GURD) request has thefollowing metadata syntax: < Report Template ID=ID#, NODE1=<node level1,label value1, assigned unique screen identification1, >, NODE2=<nodelevel2, label value2, assigned unique screen identification2, <controlID2.1, field value2.1, data location2.1>, <control ID2.2, fieldvalue2.2, data location2.2>, <..,..,..>>, NODE#n=<node level#n, labelvalue#n, assigned unique screen identification#n, <control ID#n.1, fieldvalue#n.1, data location#n.1>, <control ID#n.2, field value#n.2, datalocation#n.2>, <..,..,..>>,This response thus may include the report information having detaileditems including: UserReportID (UserID), User's report name (UserName),product (UserProd), Threshold (UserThreshold), User Report Description(UserDescript), Report Columns (UserFields), Report column headings(UserHeaders), and, in addition, customization options with fieldsindicating, inter alia, columns to display (UserHeaders), user-definedcriteria (UserCriteria), a sort order (UserOrder) and schedulingselections (UserSched), the last update of this report (UserLastUpdate)and, the Report status (if adhoc) (UserStatus), etc.

If a request is made to add a user-created report to a User_report tablemaintained by the RM Server 250, the ARD metadata message having fieldsdefined in the table provided in Appendix A is processed by the RMserver 250. An example message in metadata format to initiate theaddition of a user-created report for TVS Inbound data is as follows:ARD<USERID=jeanvnet2,ENTPID=00022924,STDRPTID=75,NAME= Payphone SummaryTVS Inbound,PRODUCT=T,CATEGORY=StandardReport,THRESHOLD=<>,SCHEDULE=A<START=199808010000,END=199808111200>,RANGETYPE=1,SCHEDTYPE=A,TIMEZONE=45,NDIALED=<8886520001˜8886520002>, DESCRIPTION=SummarizesPayphone Calls by Toll Free Number,ACTIVE=1,MMADDR=jean.jerzak@mci.com,MMTEXT= Message isin,PGT=a,PGPIN=0000000,PGTXT=654654654, EMAIL=1,PAGE=1, LANG=1234,CURR=2345>

An example message in metadata format to initiate the addition of auser-created report for TVS Outbound data is as follows:ARD<USERID=jeanvnet2,ENTPID=00022924,STDRPTID=76, NAME=Outbound TrafficCallDetail,PRODUCT=V, CATEGORY=Call Detail,THRESHOLD=<>, SCHEDULE=D<>,SCHEDTYPE=R,TIMEZONE=45,BILLING=NODE<<22924,PRS UATMASTER>>NODE<<22926,PRS FUTURE RELEASE C HQ>>NODE <<22927,PRS FUTURERELEASE A HQ>>NODE<<22928,5/92 RELEASE HQ>> NODE<<22929,PRS FUTURERELEASE B HQ>>NODE<<22940,PRS FUTURE RELEASE DHQ>>NODE<<25702,91000012CNA NAME>>,OACCESS=<2˜13>, DESCRIPTION= Outbound traffic calldetail., COLUMNS=<44˜67˜62˜36˜61˜58˜63˜64˜66˜65>,ACTIVE=1,PGT=b,PGPIN=3342423,PGTXT=Your report is ready!,EMAIL=0, PAGE=1,LANG=1234,CURR=2345>In these examples, the “NAME” field refers to the Report Name (e.g.,city summary); the “PRODUCT” field refers to the report product(Vision); the “THRESHOLD” field refers to the record count; the“DESCRIPTION” field refers to the report description; the “COLUMNS”refers to the number of columns specified for a report by the user; the“BILLING” field refers to the specified report billing entitlement,i.e., billing hierarchy; the “IACCESS” field refers to the inboundaccess type and the “OACCESS” refers to the outbound access; the“SORTBY” field indicates the report column sorting customization with“A” indicating column(s) having data to be sorted in ascending orderand, “D” indicating column(s) having data to be sorted in descendingorder; the “SCHEDULE” field referring to the scheduling type, e.g., with“A” indicating an ad-hoc report, and the user specified date range onwhich to report as indicated by the “START” and “END” fields, andadditionally, the scheduling frequency information in the case of arecurring report; the SUBTOTALCOLUMNS field, referring to the reportcolumns having data to be subtotaled; and, the “EMAIL” and “PAGE” fieldsindicating reporting notification via e-mail or paging, respectively.

Furthermore, for each of the metadata messages in Appendix A, includingthe Delete Report Definition (DRD), copy report definition (CRD), andupdate report scheduling (URS) messages, the report manager server 250responds to the Report Requestor with the processing results. In thecase of a copy report, a new User Report ID is assigned and returned byRM. When editing an existing report, e.g., a TVS (traffic) or StarODS(priced call data) report, the user may make changes to the ReportTitle, the Report Description, the Report-scheduling, the 800 numbersand thresholds. For StarODS priced call data reports, customers mayprovide additional customization options including: number of rows,report columns, access codes, access types, billing location, geographiclocation, paging notification, and e-mail notification. Morespecifically, when the user selects a report from the inventory list ora new report, an WRSEdit Screen is launched to provide the editingcapabilities which are available for the report format. WRSedit guidesthe screens through the process of retrieving the screens' data. Some ofthe screens need data which has not yet been retrieved, such as 800numbers or geographic locations. These screens manage the requests tothe DataManager object to create the get pick list (GPL) message(Appendix A), which launches the CommunicationManager object to performthis task. The CommunicationManager utilizes the RptManagerMsg object tocreate the GPL, the WRSCommWrapper for direct communication with thebackend, and the WRSReportManagerUtilParser to format the data returned.In response, the Report Manager server creates the MCIDispatcher objectand invokes the MCIRMParser class. Upon determining that the client hassent a valid message, the appropriate member function is invoked toservice the request. The Report Manager, upon receiving a message,creates the Parser object (RMParser) which takes the message apart and avalidation object is invoked which validates the message. The responseis built inside the esql wrapper function after obtaining the necessaryinformation through the stored procedure from the Informix database. TheReport Manager creates the RMServerSocket object and sends the GPLAmessage back to the client.

Having described the functionality of selecting and/or generating areport and customizing it, reference is now had to FIG. 12(c) whichdescribes the next step 650 of presenting the user with report run andsave options. Particularly, in the preferred embodiment, the user mayselect a save and exit report option, or a save and run report option.In either scenario, an WRSEdit object enables a WRSScnMgr object to savethe report to the RM server. The WRSScnMgr object launches each screenssave method which communicates with the DataManager object to place thescreens data in its corresponding WRSNode. Once all of the WRSNodeobjects have been updated, the WRSScnMgr object calls the DataManagerobject's SaveReport method to build a hash table to contain all of thereport's data. The CommunicationManager utilizes the RptManagerMsgobject to create the ARD metadata message from the hash table, theWRSCommWrapper for direct communication with the backend, and theWRSReportManagerUtilParser to handle any errors thrown by the server.The Report Manager creates the Dispatcher object, and utilizes theservices of the RMParser class and validation objects. Upon determiningthat the client has sent a valid message, the appropriate memberfunction is invoked to service the request. The response is built insidethe esql wrapper function after obtaining the necessary informationthrough the stored procedure from the RM database. The Report Managercreates the RMServerSocket object and sends the ARDA message back to theclient. When a report is submitted the selected report type andreporting criteria are sent to the Report Manager.

As illustrated in FIG. 12(c), at step 655, in reference to userselection of a Save and Run report option, the report is marked asscheduled and saved in a user_table in the Report Scheduler server 260via the report Manager. Subsequently, as indicated at step 660, theReport Scheduler server 260 sends the ARD message to the fulfillingserver which queues the report and runs the report at the specifiedtime(s), as indicated at step 665, and as described herein withreference to FIG. 11.

Generally, whether the report is to be currently run for immediate adhoc reporting, or, is scheduled for normal scheduled reporting, thefollowing sequence of operations, as indicated at steps 670-695, FIGS.12(c)-21(d), are performed: First, in response to receipt of the ARDmessage, e.g., submitted to the fulfilling server by the ReportScheduler, the fulfilling server completes the report and compresses thereport/data, as indicated at step 670. Then, the report/data is“pushed”, implementing FTP, to the fulfilling server's directory on theInbox server 270, as indicated at step 673. The TVS server 550, isresponsible for generating unique file names within their directory onthe Inbox server 270. For example, the following directory and filenaming conventions used for reports generated by the TrafficView serverare labeled inbox\files\TVs with text files having the suffix *.txt or*.txt_zip (compressed), and comma separated files having a suffix *.csvor *.csv_zip (compressed). The fulfilling server then verifies that theFTP process was successful, as indicated at step 676, and, at step 679,a notification is sent by the fulfilling server to the Report Manager tonotify the Report Manager server 250 of the location of a scheduledreport. This is accomplished by using a “NRL” metadata message.

Appendix B provides a table comprising the Notify Report Locationparameters used for the NRL Metadata messaging sent by a fulfillingserver to the RM Server 250 when a requested report is complete. Anexample NRL message sent from the TVS server 500 to the RM server 250 isas follows: NRL<TYPE=traffic, ENTPID=00022924, USERID=jeanvnet2,STDRPTID=25,USERRPTID=699, REQUESTID=32185, COMPRESS=0,LOC=/inbox/files/TVS/902507996STDRPTID25.CSV, FSIZE=198369,REPORTTITLE=Simulated Report Title, PRESORTED=1, CATEGORY=R>

Also provided in Appendix B is the acknowledgment table sent back to thefulfilling server in response.

In the preferred embodiment, the NRL message received by the RM server250 includes parameters verifying whether or not the FTP process wassuccessful. If it was successful, then the fulfilling server messagesthe Inbox that the file has been transmitted successfully bytransmitting the report name (filename) and location. When thefulfilling server encounters a problem executing a report, anotification is sent to the Report Manager. Particularly, an error flagis placed in the status field of the User_report by the Report Managerwhich is displayed to the user during Report Request. The error messagedescription will be placed in a text file and FTP'd to the fulfillingserver's report location on the Inbox server (e.g., \inbox\files\TVs) bythe fulfilling server.

Referring to FIG. 12(d), step 679, once the RM server 250 has receivedthe NRL message from the fulfilling server, it verifies the file'spresence, as indicated at step 682. The RM server 250 then builds ametadata file, e.g., by compressing the appropriate metadata (fordisplaying the report) into a .MTD file, as indicated at step 685. This.MTD file is utilized by the Report Viewer to know how to display thereport. The Report Manager server creates a file including the metadatausing the same file name as the report/data file, but having thefollowing suffix: *.mtd or *.mtd_zip indicating a metadata or compressedmetadata file, respectively.

Appendix F details the parameters that are passed in the GET METADATAmessaging for indicating to the Report Viewer how to display a requestedreport. For example, a GET METADATA message corresponding to an unpricedTVS fulfilling server report is as follows:<METADATA=<CRITERIA=<Name=UsageSummary292{circumflex over( )}ADescription= This report summarizes calls based on calltype.{circumflex over ( )}AReport_Level=<INBOUND<<90000001,90000001><NA,NA><NA,NA>>INBOUND<<90000002,90000002><,><,>>>{circumflex over( )}AOptions={circumflex over ( )}AScheduling _Information={circumflexover ( )}AOne_Time={circumflex over( )}ADates=<06/01/199800:00/˜07/01/199800: :00,>{circumflex over( )}ATimezone=EST,Lang=1234,Curr=2345>DEFAULT_GRAPH _MODE=0{circumflexover ( )}ADEFAULT_GRAPH_TYPE=0{circumflex over ( )}ADEFINE_X_AXIS=0{circumflex over ( )}AX_AXIS_COLUMN= {circumflex over ( )}ADEFAULT_Y_COLUMNS=<>{circumflex over ( )}ACOLUMN_DISPLAY_ORDER=<105{circumflex over ( )}A114{circumflex over( )}A67{circumflex over ( )}A62{circumflex over ( )}A36{circumflex over( )}A61{circumflex over ( )}A58{circumflex over ( )}A63{circumflex over( )}A64 {circumflex over ( )}A66{circumflex over ( )}A65>{circumflexover ( )}ASORT_ALLOWED=1{circumflex over ( )}APRESORTED=0{circumflexover ( )}A PRESUBTOTALED=1{circumflex over ( )}ATOTALMODE=0{circumflexover ( )}ASORT_COLUMN S=<105A>{circumflex over ( )}ASUBTOTAL_COLUMNS=<>{circumflex over ( )}ASELECTED_SECTION=0{circumflexover ( )}A METACOLUMN=<META_COLUMN_ID=105{circumflex over ( )}ACOLUMN_LABEL=Usage Description{circumflex over( )}ADATATYPE=S{circumflex over ( )}ADECIMAL=0{circumflex over ( )}AHIDEABLE=1{circumflex over ( )}AGRAPHABLE=0{circumflex over( )}AWIDTH=20{circumflex over ( )}ACALCULATE=0{circumflex over ( )}ACALCULATE_EXPRESSION=>{circumflex over( )}AMETACOLUMN=<META_COLUMN_ID=114{circumflex over ( )}ACOLUMN_LABEL=Range/DistanceDescription{circumflex over( )}ADATATYPE=S{circumflex over ( )}ADECIMAL =0{circumflex over( )}AHIDEABLE=1{circumflex over ( )}AGRAPHABLE=0{circumflex over( )}AWIDTH=20{circumflex over ( )}ACALCULATE=0{circumflex over ( )}ACALCULATE_EXPRESSION=>{circumflex over( )}AMETACOLUMN=<META_COLUMN_ID=67{circumflex over ( )}ACOLUMN_LABEL=Calls{circumflex over ( )}ADATATYPE=I{circumflex over( )}ADECIMAL=0{circumflex over ( )}AHIDEABLE=1{circumflex over ( )}AGRAPHABLE=1{circumflex over ( )}AWIDTH=7{circumflex over( )}ACALCULATE=0{circumflex over ( )}ACALCULATE_EXPRESSION=> {circumflexover ( )}AMETACOLUMN=<META_COLUMN_ID=62{circumflex over( )}ACOLUMN_LABEL=% Calls{circumflex over ( )}A DATATYPE=N{circumflexover ( )}ADECIMAL=1{circumflex over ( )}AHIDEABLE=1{circumflex over( )}AGRAPHABLE=1{circumflex over ( )}AWIDTH=7{circumflex over ( )}ACALCULATE=0{circumflex over ( )}ACALCULATE_EXPRESSION=>{circumflex over( )}A METACOLUMN=<META_COLUMN_ID=36{circumflex over( )}ACOLUMN_LABEL=Minutes{circumflex over ( )}A DATATYPE=N{circumflexover ( )}ADECIMAL=1{circumflex over ( )}AHIDEABLE=1{circumflex over( )}AGRAPHABLE=1{circumflex over ( )}AWIDTH=8{circumflex over ( )}ACALCULATE=0{circumflex over ( )}ACALCULATE_EXPRESSION=>{circumflex over( )}A METACOLUMN=<META_COLUMN_ID=61{circumflex over ( )}ACOLUMN_LABEL=%Min{circumflex over ( )}A DATATYPE=N{circumflex over( )}ADECIMAL=1{circumflex over ( )}AHIDEABLE=1{circumflex over( )}AGRAPHABLE=1{circumflex over ( )}A WIDTH=5{circumflex over( )}ACALCULATE=0{circumflex over ( )}ACALCULATE_EXPRESSION=>{circumflexover ( )}A METACOLUMN=<META_COLUMN_ID=58{circumflex over( )}ACOLUMN_LABEL=Amount{circumflex over ( )}ADATATYPE =C{circumflexover ( )}ADECIMAL=2{circumflex over ( )}AHIDEABLE=1{circumflex over( )}A GRAPHABLE=1{circumflex over ( )}AWIDTH=7{circumflex over( )}ACALCULATE=0{circumflex over ( )}ACALCULATE_EXPRESSION=> {circumflexover ( )}AMETACOLUMN=<META_COLUMN_ID=63{circumflex over( )}ACOLUMN_LABEL=% Amt{circumflex over ( )}A DATATYPE=N{circumflex over( )}ADECIMAL=1{circumflex over ( )}AHIDEABLE=1{circumflex over( )}AGRAPHABLE=1{circumflex over ( )}AWIDTH=5{circumflex over ( )}ACALCULATE=0{circumflex over ( )}ACALCULATE_EXPRESSION=>{circumflex over( )}A METACOLUMN=<META_COLUMN_ID=64{circumflex over( )}ACOLUMN_LABEL=Avg Min/Call {circumflex over( )}ADATATYPE=N{circumflex over ( )}ADECIMAL=2{circumflex over( )}AHIDEABLE=1{circumflex over ( )}AGRAPHABLE=1{circumflex over ( )}AWIDTH=12{circumflex over ( )}ACALCULATE=0{circumflex over( )}ACALCULATE_EXPRESSION=>{circumflex over ( )}AMETACOLUMN=<META_COLUMN_ID=66{circumflex over ( )}ACOLUMN_LABEL=AvgAmt/Call{circumflex over ( )}A DATATYPE=N{circumflex over( )}ADECIMAL=2{circumflex over ( )}AHIDEABLE=1{circumflex over( )}AGRAPHABLE=1{circumflex over ( )}AWIDTH=12 {circumflex over ( )}ACALCULATE=0{circumflex over ( )}ACALCULATE_EXPRESSION=>{circumflex over( )}A METACOLUMN=<META_COLUMN_ID=65{circumflex over( )}ACOLUMN_LABEL=Avg Amt/Min{circumflex over ( )}ADATATYPE=N{circumflex over ( )}ADECIMAL=2{circumflex over( )}AHIDEABLE=1{circumflex over ( )}AGRAPHABLE=1{circumflex over ( )}AWIDTH=11{circumflex over ( )}ACALCULATE=0{circumflex over( )}ACALCULATE_EXPRESSION=>>> *<METADATA= <CRITERIA= <Name=My Report,Total=Totals are located at the bottom of the report., Description=Myreport description, Number_Dialed=<800#1, 800#2, 800#n>,Scheduling_Information= Recurring, Dates= Monthly>>DEFAULT_GRAPH_MODE=1, DEFAULT_GRAPH_TYPE=1, DEFINE_X_AXIS=1,X_AXIS_COLUMN=2, DEFAULT_Y_COLUMNS=<5,6>,COLUMN_DISPLAY_ORDER=<1,2,3,4,5,6>, COLUMN_STORED_ORDER=<4,3,2,5,6,1>,SORT_ALLOWED=1, PRESORTED = 1, TOTALMODE=3, SUBTOTCOL=<5,6>, SELECTEDSECTION=1, METACOLUMN=<META_COLUMN_ID=1, COLUMN_LABEL=name, DATATYPE=S,DECIMAL=0, HIDEABLE=1, GRAPHABLE=0, WIDTH=10, CALCULATE=1,CALCULATE_EXPRESSION=<4 / 7>>>>

Once the metadata file corresponding to the requested report is build bythe Report Manager, the RM ftp's the .MTD file to the Inbox server, asindicated at step 688, FIG. 12(d). The RM server additionally updatesthe User_report table status field with a status “C” indicatingcompletion, as indicated at step 691.

Once the Report Manager has updated the status field, the RM server 250then adds the report to the user's Inbox, as indicated at step 693.

Appendix C provides a table showing the fields for the metadatamessaging between the RM server 250 and the Inbox server 270 for addingan item into the StarWRS system Inbox server 270, and the respectiveacknowledgment message format back from the Inbox server. In the “A”message found in Appendix C, the “LOC” field includes information aboutwhere the report data is located. For example, a metadata messageindicating to the Inbox server that an unpriced TVS fulfilling serverreport is available is shown as:A<CATEGORY=R,TYPE=traffic,REQUESTID=32197,USERID=LynneLevy2,RPTID=150,PRIORITY=,COMPRESS=0,UNOTIFY=0,MMADDR=,MMTEXT=,PGT=,PGPIN=,PGTXT=,RPTCATEGORY= Service Location &Hour, LOC=/inbox/files/testTVS/902512294STDRPTID10.CSV,ENTPID=10324488,RQSTDT1998-01-02 15:18,FSIZE=3705,RPTTITLE=summary byService Location and Hour,MSIZE=3322>Particularly, the RM server supplies a metadata “A” message to the Inboxindicating the FTP file location. Via the report viewer, the report isnow available for viewing, downloading, saving, or printing by the user,as indicated at step 695, and as described in further detail inco-pending U.S. patent application Ser. No. ______ (D#11041), entitledMULTI-THREADED WEB BASED IN-BOX FOR REPORT MANAGEMENT, the contents anddisclosure of which are incorporated by reference as if fully set forthherein. Particularly, as shown in the exemplary nMCI home page in FIG.4, the nMCI Interact Message Center icon 77 may be selected which willcause the display of a web page including the message center dialogwindow. From the message center dialog windoe, a user may select fromamong three tabs, one of which, a reports tab, enables the retrieval ofboth a data file and a metadata file from the Inbox Server correspondingto those reports that have been run and available for customer viewing.Information provided for display by the message center display 325 isprovided by the User_table which keeps track of the status of allreports for a particular user. By double-clicking a chosen report, areport viewer application is enabled to display the chosen report on aweb-page.

Referring back to FIG. 6, the Report Viewer 215 interfaces with theuser's Inbox 210 for presenting to the customer the various type ofreports received at the Inbox. It should be understood that all ReportRequestor and Report Viewer applications communicate with the RM server250 through the use of the common object communication classes.

Particularly, as shown in FIG. 6, the Inbox server 270 interface withthe Inbox Client 210 supports messaging that enables the User to removean item from the Inbox, e.g., delete a report, or, to delete all itemsfrom the Inbox, e.g., for a particular Enterprise and User ID as well asother associated reports.

Appendix G illustrates the parameters used in the metadata messagingbetween the Inbox client and the Inbox server. Particularly, the List“L” message is a synchronous request for a list of all Inbox items for aspecific user. The Inbox fetch “F” function is a bulk transfer requestthat enables bulk transfer of the requested file to the Inbox client.

Referring back to FIG. 12(b), after editing or modifying an existingreport, the user may simply select to save the report and exit. In thiscase, the ARD message is sent from the Report Requestor client to the RMserver and is saved in the RM inventory database for subsequentexecution. Consequently, the report is flagged as incomplete in theUser_table and may not be run until a run option for that report ischosen. Otherwise, the report may be immediately scheduled if the userselects the save and run button.

As described, Metadata messaging is used throughout the variouscomponents of the StarWRS system 200. The format of an interface messagethat is sent to the Report Scheduler server is identical to the formatas shown in Table 3 as is the interface messaging format returned by theRS server 260 in Table 2. Thus, in the case of automatic recurringreports, a variation of the process outlined in FIG. 12(c) occurs atstep 660, whereby the ARD request is instead sent from the reportscheduler to the fulfilling server at the programmed frequency.Particularly, when a report is required to be run, the Report schedulerserver 260 (FIG. 6) sends an ARD request to the fulfilling server in ametadata message format having parameters as included in the Add ReportDefinition table in Appendix D. Upon processing of the metadata message,the fulfilling server will respond to the report Scheduler with anacknowledgment of the command, and the process outlined in FIGS. 12(c)and 12(d) is executed.

As mentioned herein with respect to FIG. 2, the messages created by theclient Java software are transmitted to the StarWeb (DMZ) Server 24 overHTTPS. For incoming (client-to-server) communications, the DMZ Webservers 24 decrypt a request, authenticate and verify the sessioninformation. The logical message format from the client to the Webserver is shown as follows: || TCP/IP || encryption || http || webheader || dispatcher header || proxy-specific data ||where “||” separates a logical protocol level, and protocols are nestedfrom left to right. FIG. 13 illustrates a specific message sent from theclient browser to the desired middle tier server for the particularapplication. As shown in FIG. 13, the client message 340 includes an SSLencryption header 342 and a network-level protocol HTTP/POST header 344which are decrypted by the DMZ STarWeb Server(s) 24 to access theunderlying message; a DMZ Web header 346 which is used to generate acookie 341 and transaction type identifier 343 for managing theclient/server session; a dispatcher header 345 which includes the targetproxy identifier 350 associated with the particular type of transactionrequested; proxy specific data 355 including the application specificmetadata utilized by the target proxy to form the particular messagesfor the particular middle tier server providing a service; and, thenetwork-level HTTP/POST trailer 360 and encryption trailer 365 which arealso decrypted by the DMZ Web server layer 24.

After establishing that the request has come from a valid user andmapping the request to its associated session, the request is thenforwarded through the firewall 25 over a socket connection 23 to one ormore decode/dispatch servers 26 located within the corporate Intranet30. The messaging sent to the Dispatcher will include the useridentifier and session information, the target proxy identifier, and theproxy specific data. The decode/dispatch server 26 authenticates theuser's access to the desired middle-tier service.

As shown in FIG. 13, the StarWeb server forwards the Dispatcher headerand proxy-specific data to the Dispatcher, “enriched” with the identityof the user (and any other session-related information) as provided bythe session data/cookie mapping, the target proxy identifier and theproxy-specific data. The dispatch server 26 receives the requestsforwarded by the Web server(s) 24 and dispatches them to the appropriateapplication server proxies. Particularly, as explained above withrespect to FIG. 6, the dispatch server 26 receives request messagesforwarded by the DMZ Web servers and dispatches them to the appropriateserver proxies. The message wrappers are examined, revealing the userand the target middle-tier service for the request.

A first-level validation is performed, making sure that the user isentitled to communicate with the desired service. The user'sentitlements in this regard are fetched by the dispatch server fromOrder Entry server 280 at logon time and cached. Assuming that theRequestor is authorized to communicate with the target service, themessage is then forwarded to the desired service's proxy, which, in theaccordance with the principles described herein, comprises: 1) a reportmanager proxy 250′ corresponding to the RM Server 250, 2) a reportscheduler proxy 260′ corresponding to the RS Server 260, and 3) an inboxserver proxy 270′ corresponding to the Inbox Server 270. Each of theseproxy processes further performs: a validation process for examiningincoming requests and confirming that they include validly formattedmessages for the service with acceptable parameters; a translationprocess for translating a message into an underlying message ornetworking protocol; and, a management process for managing thecommunication of the specific customer request with the middle-tierserver to actually get the request serviced. Data returned from themiddle-tier server is translated back to client format, if necessary,and returned to the dispatch server as a response to the request.

FIGS. 14(a) and 14(b) are schematic illustrations showing the messageformat passed between the Dispatcher 26 and the application specificproxy (FIG. 14(a)) and the message format passed between the applicationspecific proxy back to the Dispatcher 26 (FIG. 14(b)). As shown in FIG.14(a), all messages between the Dispatcher and the proxies, in bothdirections, begin with a common header 110 to allow leverage of commoncode for processing the messages. A first portion of the header includesthe protocol version 115 which may comprise a byte of data foridentifying version control for the protocol, i.e., the message formatitself, and is intended to prevent undesired mismatches in versions ofthe dispatcher and proxies. The next portion includes the message length120 which, preferably, is a 32-bit integer providing the total length ofthe message including all headers. Next is the echo/ping flag portion122 that is intended to support a connectivity test for thedispatcher-proxy connection. For example, when this flag is non-zero,the proxy immediately replies with an echo of the supplied header. Thereshould be no attempt to connect to processes outside the proxy, e.g. theback-end application services. The next portion indicates the Sessionkey 125 which is the unique session key or “cookie” provided by the Webbrowser and used to uniquely identify the session at the browser. Asdescribed above, since the communications middleware is capable ofsupporting four types of transport mechanisms, the next portion of thecommon protocol header indicates the message type/mechanism 130 whichmay be one of four values indicating one of the following four messagemechanisms and types: 1) Synchronous transaction, e.g., a binary 0; 2)Asynchronous request, e.g., a binary 1; 3) Asynchronous poll/reply,e.g., a binary 2; 4) bulk transfer, e.g., a binary 3.

Additionally, the common protocol header section includes an indicationof dispatcher-assigned serial number 135 that is unique across alldispatcher processes and needs to be coordinated across processes (likethe Web cookie (see above)), and, further, is used to allow for failoverand process migration and enable multiplexing control between theproxies and dispatcher, if desired. A field 140 indicates the status isunused in the request header but is used in the response header toindicate the success or failure of the requested transaction. Morecomplete error data will be included in the specific error messagereturned. The status field 140 is included to maintain consistencybetween requests and replies. As shown in FIG. 14(a), the proxy specificmessages 375 are the metadata message requests from the report requestorclient and can be transmitted via synchronous, asynchronous or bulktransfer mechanisms. Likewise, the proxy specific responses are metadataresponse messages 380 again, capable of being transmitted via a synch,asynch or bulk transfer transport mechanism.

It should be understood that the application server proxies can eitherreside on the dispatch server 26 itself, or, preferably, can be residenton the middle-tier application server, i.e., the dispatcher front endcode can locate proxies resident on other servers.

As mentioned, the proxy validation process includes parsing incomingrequests, analyzing them, and confirming that they include validlyformatted messages for the service with acceptable parameters. Ifnecessary, the message is translated into an underlying message ornetworking protocol. A list of Report Manager and Inbox proxy errormessages can be found in Appendix E. If no errors are found, the proxythen manages the communication with the middle-tier server to actuallyget the request serviced. The application proxy supports applicationspecific translation and communication with the back-end applicationserver for both the Web Server (java applet originated) messages andapplication server messages.

Particularly, in performing the verification, translation andcommunication functions, the Report Manager server, the Report Schedulerserver and Inbox server proxies each employ front end proxy C++ objectsand components. For instance, a utils.c program and a C++ componentslibrary, is provided for implementing general functions/objects. VariousC++ parser objects are invoked which are part of an object class used asa repository for the RM metadata and parses the string it receives. Theclass has a build member function which reads the string which includesthe data to store. After a message is received, the parser object iscreated in the RMDispatcher.c object which is a file comprising thebusiness logic for handling metadata messages at the back-end. It usesthe services of an RMParser class. Upon determining that the client hassent a valid message, the appropriate member function is invoked toservice the request. Invocation occurs in MCIRMServerSocket.C when anincoming message is received and is determined not to be a talarianmessage. RMSErverSocket.c is a class implementing the message managementfeature in the Report Manager server. Public inheritance is fromMCIServerSocket in order to create a specific instance of this object.This object is created in the main loop and is called when a messageneeds to be sent and received; a Socket.c class implementing client typesockets under Unix using, e.g., TCP/IP or TCP/UDP. Socket.C is inheritedby ClientSocket.C:: Socket(theSocketType, thePortNum) andServerSocket.C:: Socket(theSocketType, thePortNum) when ClientSocket orServerSocket is created. A ServerSocket.c class implements client typesockets under Unix using either TCP/IP or TCP/UDP. ServerSocket.C isinherited by RMServerSocket when RMServerSocket is created. AnInboxParser.c class used as a repository for the RM Metadata. The class'“build” member function reads the string which includes the data tostore and the class parses the string it receives. After a message hasbeen received, the MCIInboxParser object is created in inboxutl.c whichis a file comprising the functions which process the Inbox requests,i.e, Add, Delete, List, Fetch and Update. Additional objects/classesinclude: Environ.c which provides access to a UNIX environment;Process.c which provides a mechanism to spawn slave processes in theUNIX environment; Daemon.c for enabling a process to become a daemon;Exception.c for exception handling in C++ programs; and, RMlog.c forfacilitating RM logging. In addition custom ESQL code for RM/databaseinterface is provided which includes the ESQC C interface (Informix)stored procedures for performing the ARD, DRD, DUR, URS, GRD, CRD, andGPL messages. The functions call the stored procedures according to themessage, and the response is built inside the functions depending on thereturned values of the stored procedures. A mainsql.c program providesthe ESQL C interface for messages from the report manager and reportviewer.

Outgoing (server-to-client) communications follow the reverse route,i.e., the proxies feed responses to the decode/dispatch server andcommunicate them to the DMZ Web servers over the socket connection. TheWeb servers will forward the information to the client using SSL. Thelogical message format returned to the client from the middle tierservice is shown as follows: || TCP/IP || encryption || http || webresponse || dispatcher response || proxy-specific response ||where “||” separates a logical protocol level, and protocols nested fromleft to right.

The foregoing merely illustrates the principles of the presentinvention. Those skilled in the art will be able to devise variousmodifications, which although not explicitly described or shown herein,embody the principles of the invention and are thus within its spiritand scope.

1.-19. (canceled)
 20. A reporting system comprising: a report managerconfigured to communicate with a browser over a secure session and tomaintain a reporting item associated with a customer, the reporting itemcomprising a report data type or a report customization feature for areport to be generated; and a data retrieval device configured toretrieve customer specific data from a network of the customer, whereinthe report manager is further configured to receive a request messagecomprising a metadata description of the reporting item, the metadatadescription of the reporting item being verified and forwarded to thedata retrieval device for retrieval of the customer specific data,wherein the report manager is further configured to use the customerspecific data and the metadata description to dynamically generate thereport.
 21. A system according to claim 20, wherein the secure sessionis managed by a secure server, the secure server supporting a securesocket connection enabling encrypted communication with the browser. 22.A system according to claim 20, wherein the report is further determinedbased on a customization option and a user option.
 23. A systemaccording to claim 20, wherein the request message is generated by arequestor application and is verified to ensure valid formatting.
 24. Asystem according to claim 23, wherein the requestor application providespresentation of a report request menu comprising a user selectablereporting option for the report in accordance with a predeterminedcustomer entitlement.
 25. A system according to claim 23, wherein therequestor application provides user selection of a specific reportingoption for a desired report, and in response to the selection, generatesthe request message.
 26. A system according to claim 20, wherein thedata retrieval device is further configured to retrieve call detailinformation generated from an element of the network.
 27. A systemaccording to claim 20, wherein a requestor applet enables customerscheduling of report request metadata descriptions to be communicatedfrom the report manager to the retrieval device.
 28. A system accordingto claim 27, wherein a web server is configured to communicate with thebrowser and to provide a report requester applet capable of presentingthe reporting item to the customer.
 29. A system according to claim 20,wherein the customer specific data information relates to usage of thenetwork.
 30. A system according to claim 20, wherein the customerspecific data information relates to unpriced traffic call detail data.31. A system according to claim 20, wherein the retrieval device isfurther configured to generate statistical data based on retrievedcustomer-specific call detail data.
 32. A system according to claim 20,wherein the retrieval device communicates call detail data in real-timeto the browser.
 33. A system according to claim 20, wherein aworkstation is configured to run the browser and to interface a reportviewing device for receiving the metadata description of a requestedreport type and corresponding retrieved customer specific data.
 34. Amethod for providing reporting, the method comprising: maintaining areporting item associated with a customer, the reporting item comprisinga report data type or a report customization feature for a report to begenerated; retrieving customer specific data from a network of thecustomer; receiving a request message comprising a metadata descriptionof the reporting item; verifying the metadata description of thereporting item for retrieval of the customer specific data; dynamicallygenerating the report based on the customer specific data and themetadata description; and communicating with a browser over a securesession to present the report.
 35. A method according to claim 34,wherein the secure session is managed by a secure server, the secureserver supporting a secure socket connection enabling encryptedcommunication with the browser.
 36. A method according to claim 34,wherein the report is further generated based on a customization optionand a user option.
 37. A method according to claim 34, wherein therequest message is generated by a requestor application and is verifiedto ensure valid formatting.
 38. A method according to claim 37, whereinthe requestor application provides presentation of a report request menucomprising a user selectable reporting option for the report inaccordance with a predetermined customer entitlement.
 39. A methodaccording to claim 37, wherein the requestor application provides userselection of a specific reporting option for a desired report, and inresponse to the selection, generates the request message.
 40. A methodaccording to claim 34, further comprising: retrieving call detailinformation generated from an element of the network.
 41. A methodaccording to claim 34, wherein a requester applet enables customerscheduling of report request metadata descriptions to be communicatedfrom the report manager to the retrieval device.
 42. A method accordingto claim 41, wherein a web server is configured to communicate with thebrowser and to provide a report requestor applet capable of presentingthe reporting item to the customer.
 43. A method according to claim 34,wherein the customer specific data information relates to usage of thenetwork.
 44. A method according to claim 34, wherein the customerspecific data information relates to unpriced traffic call detail data.45. A method according to claim 34, further comprising: generatingstatistical data based on retrieved customer-specific call detail data.46. A method according to claim 34, wherein the retrieval devicecommunicates call detail data in real-time to the browser.
 47. A methodaccording to claim 34, wherein a workstation is configured to run thebrowser and to interface a report viewing device for receiving themetadata description of a requested report type and correspondingretrieved customer specific data.
 48. A reporting system comprising:means for maintaining a reporting item associated with a customer, thereporting item comprising a report data type or a report customizationfeature for a report to be generated; means for retrieving customerspecific data from a network of the customer; means for receiving arequest message comprising a metadata description of the reporting item;means for verifying the metadata description of the reporting item forretrieval of the customer specific data; means for dynamicallygenerating the report based on the customer specific data and themetadata description; and means for communicating with a browser over asecure session to present the report.
 49. A system according to claim48, wherein the metadata description includes a report descriptionobject for specifying presentation of the report and data export andreporting printing services.